From: "Peter Trei" <trei@process.com>
Date: Mon, 6 Jan 1997 10:47:17 -0800 (PST)
To: cypherpunks@toad.com
Subject: [DES] DES Key Recovery Project, Progress Report #5
Message-ID: <199701061847.KAA28453@toad.com>
MIME-Version: 1.0
Content-Type: text/plain


DES Key Recovery Project, Progress Report #5
6 January 1997

Well, the New Year brings changes....

1. I'm astonished at the low level of reaction RSA's 
announcement that they will be sponsoring a DES Challenge, 
with a $10,000 cash prize.

I've been working with people at RSA to get this set up. It looks like
there'll be an ascii-plaintext challenge (we won't know the full
plaintext - just that it's ascii, and long enough to be unambigious),
and the full prize will go the first person who emails them the key. 

This is pretty much what we need to recruit a large number of 
otherwise dis-interested people, and their machines. The code
will be a tad slower than for an attack where we know the full
plaintext of the block sought, but not much.

2. As for my code for WinTel machines - it's very close 
to an initial alpha release (squashing a few last bugs). I 
intend this to be used only for identifying porting issues. 
The first 'real' version is a couple weeks away. 

Once the alpha is out, I'll be looking at the new assembly
language code from Eric Young and Svend Mikkelsen to see
how it compares with mine. Since Eric independently matched
my speed in the DES round, I want to see if he is using any
different tricks than I.

When it's released, my code will be able to:

1. Run a validity and speed test.
2. Accept a specified 32 bit 'chunk' of the keyspace to test. When it
   finishes a chunk, it appends information about whether it found the
   key to a results file, and also any half-matches it found along
   with a checksum. The latter two items help make cheating and
   sabotage more difficult. 
3. Read it's input (plaintext, IV, etc) from a file. After the actual
   DES Challenge is announced, I'll hardwire that challenge into the
   program.
4. Periodically checkpoint it's status to a file. This is so that the
   program can be stopped at any time neccesary, without losing more
   than a few minutes work. At startup, it looks in this file for
   where to continue searching, unless instructed otherwise.  

It will NOT run as a screen saver. It's actually more efficient to run
as a low-priority task in the background - that way it soaks up unused
cycles even when a screen saver is not in operation. If someone else
want's to incorporate it into an SS, go ahead.

The alpha will run in a DOS box under Win95 and WinNT. A GUI
interface may come along later.

It will NOT talk to a keyspace server, though the format of the 
input and output should make it possible to add this in the 
future. I don't have time to develop both myself, and while 
people on the lists have proposed any number of complex schemes 
for setting up and managing a server, no one in the US seems
willing to do the work (I'm worried about violating ITAR/EAR).
I have a pretty good idea what needed in a server. At very least, I'd
like to have people register the fact that they are taking part, so we
get some idea of the level of effort being expended.

The very first time it is started up on a given machine, if 
it is not given a specific chunk at which to start, it will 
pick one at random. The checkpointing scheme means that on 
later runs, it will pick up where it left off, advancing to 
the next chunk as it completes each one.

For this purpose, we don't need cryptographically strong PRNG,
just one that provides a fairly smooth distribution of results.

This means that the search *will* complete, but the time is not
as good as a carefully doled-out keyspace would provide. If you
want to do the math, go ahead, but I think it will average about
twice as long as a purely doled-out search to search the whole
keyspace, and somewhat less to search half the keyspace.

Peter Trei
trei@process.com