From: Ryan Russell/SYBASE <Ryan.Russell@sybase.com>
Date: Wed, 24 Jul 1996 09:17:07 +0800
To: "Peter Trei" <trei@sybase.com>
Subject: Re: Brute Force DES
Message-ID: <9607231746.AA26532@notesgw2.sybase.com>
MIME-Version: 1.0
Content-Type: text/plain


How about harder logistical problem?

I had considered the possibility of cracking DES
once and for all (I was specifically thinking of
crypt(3), but it applies just as well for
DES in general..) and instead of trying up a bunch
of computers for however many months it took to crack 
a single key...  Let's tie up everyone's extra storage
and store the results as each key is generated..

Yes, I realize that it's a rather large amount of storage...

Then key lookups could be done at will, reverse DNS
style..

    Ryan

---------- Previous Message ----------
To: frissell, cypherpunks, trei
cc: 
From: trei @ process.com ("Peter Trei") @ smtp
Date: 07/22/96 04:55:17 PM
Subject: Re: Brute Force DES

> Peter wrote:
> >Any one up for a distributed brute force attack on single DES? My 
> >back-of-the-envelope calculations and guesstimates put this on the
> >hairy edge of doability (the critical factor is how many machines can
> >be recruited - a non-trivial cash prize would help). 

Duncan wrote: 
> I volunteer my 120 MHZ Pentium.  A lot more Pentiums are out there now than
> a year ago.  That makes it more feasible.  A lot more people with full net
> connections.  Like most Americans, I have a flat rate net connection and a
> flat rate local phone connection so could run a cracking session permanently
> (as long as no one tells my ISP).  We need a full test of the Winsock
> cracking client in any case.  It wasn't working very well last time.
> 
> DCF

<back-of-envelope>

In my terminology, 'hairy edge of doability" means we have a shot
at success, but I wouldn't bet the farm on it.

I thought that I might bet a couple hundred bucks, though.

Sadly, after further calculation, I'm not so sure if it's doable just yet.

What I'm looking at is a known plaintext attack on single ECB DES, 
using a brute-force test to cycle through the key space. People 
would get chunks of keyspace to test from a central server or 
servers, and would be motivated to take part by a cash prize for
the lucky person who finds the key.

Lets do  the numbers:

Single DES has the security of 56 bits of key - there are 64 bits in the
keys, but 8 of them are parity bits which add nothing to security.

2^56  = 7.205e16 keys (which is a whopping big number)

Let's guess that we can recruit the equivalent of full-time on 1000
machines.

7.205e13 keys/machine.

Let's guess that we have about a month before people start to lose 
interest - so we want to be more than 1/2 done by then. Lets say
we want to sweep the whole space in 40 days.

1.8e12 keys/machine/day 

~21,000,000 keys/machine/second

The fastest general purpose, freely available des implementation I'm
aware of is libdes. by Eric Young. With this, I can do a set_key in 
15.8 us, and an ecb_encrypt in 95 us/block. That adds up to 
about 9,000 keytests/sec (this is on a 90 MHz P5, running NT).

I'm looking at ideas to speed up DES - if I'm willing to use
honking great lookup tables, the permutation steps  can be done 
more quickly than libdes. I'm also looking at implementing the
algolrithm in hand-optimized P5 assembler.  (It's been years since
I've done a major assembler project - the P5 has some truely weird
features to be considered, but also has (some) internal 64 bit
registers to play with).

Let's guess that I can speed up a key-test up by a factor of 10. (This is
not a slur on Eric's code - it's extremely clever, but not optimized
for any particular processor, or for key-testing.  Note that the keytest 
described above takes about 10,000 cycles/test.)

That gets my workstation up to about 90,000 keys a second, which is
still almost a factor of 250 too slow. 

I'm going ahead with my work on a faster DES keytester, but unless
optimizing gives an astounding win, I now think a distributed bruting 
effort is a bit pre-mature.

What will make this brute doable, if not now, then in the near future?

1. Faster Processors - Moore's Law is still holding. A year ago, my
90 MHz Pentium was one of the faster machines taking part in the
40-bit RC4 crack. Now, it's passe.

2. More processors. The number of people on the internet continues
to grow rapidly.

3. More interest - Crypto awareness has greatly increased in the
last year, and a real cash prize (say, over $500) will generate both
publicity and interest.

These factors all multiply together. The number of cycles that could
probably be recruited is increasing at a fast rate. A major part of the
work will be a keyspace distribution mechanism which can handle
the load (this was a major stumbling block last year). 

</back-of-envelope>

Peter Trei
trei@process.com

Disclaimer: This has nothing to do with my employer.