[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Can we kill single DES? #2
Yesterday I posted 'Can we kill single DES?', and I count about 20
responses, counting both those to the list, and those to me personally.
One offer was made of a $1000 reward in return for a crack, if the
offerer could make publicity hay of the offer (no, I don't have a problem
with that, but I'd like it set up so that others could add to the reward as
well). If the reward got big enough ($10k?) I think it would be a
major incentive for otherwise uninterested people to run the screen
saver. On the other hand, it might get into legal hassles - I don't know.
The total cpu power pledged at the moment could sweep the key
space in 300-400 years, if my speed estimates are correct.
I'm concerned that the key scheduling may be worse than I estimated
in my earlier letter - Phil Karn's code to generate the key schedule takes
about 150x as long as my code takes to test the key. However, neither he
nor I have bothered yet to optimize this part of the code, or reduce it to
assembler. It looks like I can get this part down to two instructions
per round, at least most of the time.
-----------
I'm really concerned about the problem of a search failing, or
succeeding only after too long a time. Perry's proposal of about
a month of real time is on the right order, though I could see up
to 3 months being possible.
Here's what I'm thinking of doing:
1. Writing a prose description of the platform independent speedups.
2. Writing a proposal for a client-server protocol for doling out
keyspace and returning results. Aside from the direct Internet
interface, there will also be a mechanism for i/o via plain text -
suitable for cut-and-paste, or simple CLI interfaces.
3. Writing a generic 'C' implementation of the keysearch client and server,
which demonstrates the i/o and the various speedups. This should
be highly portable (but probably non-exportable). You'd also be able
to search randomly, or from a designated starting point.
4. Work on the screen-saver based version of the client.
I'm still very interested in hearing about any hardware based
approaches actually underway - not a pile of wild-assed guesses
and hopes.
Those who want to look at a fast DES in assembler should check
out Phil's 386 version, which includes both generic C and a variety
of assembler implementations for the actual encryption step. See:
ftp://idea.sec.dsi.unimi.it/pub/security/crypt/code/des386.zip
Phil also has a Pentium version (a little slower than mine)
which he mails to US citizens.
Peter Trei
[email protected]