[1135] in cryptography@c2.net mail archive
Re: Better DES challenge update
daemon@ATHENA.MIT.EDU (Dave Emery)
Tue Jul 1 15:51:38 1997
From: Dave Emery <die@pig.die.com>
In-Reply-To: <y8a4tagrqtn.fsf@horten.artcom.de> from "Andreas Bogk" at "Jun 30, 97 06:36:04 pm"
To: andreas@artcom.de (Andreas Bogk)
Date: Mon, 30 Jun 1997 23:21:44 -0400 (EDT)
Cc: die@die.com, eli@gs160.sp.cs.cmu.edu, cryptography@c2.net,
crisp@netcom.com
Reply-To: die@die.com
qhAndreas Bogk wrote :
> >>>>> "Dave" == Dave Emery <die@pig.die.com> writes:
>
> Dave> As I see such an architecture, the ASIC would either
> Dave> contain a second slow DES path (more or less similar to a
> Dave> current DES chip and not pipelined like the main engine) or
> Dave> logic to insert out of order keys into the main pipelined
> Dave> engine. This would allow the chip to buffer in a FIFO and
> Dave> asynchronously test hits on possible keys to any reasonable
> Dave> desired depth without going off chip. This architecture
>
> Of course, just building sixteen un-pipelined engines would require
> about the same number of gates. It could even be more efficient (in
> terms of cost vs. speed) not to test hits before round 16.
I've thought about that tradeoff and am really not sure. A
pipelined cascade could well have S boxes done in flow through gates,
whereas a sequential traditional one at a time DES engine would probably
wind up with multiple traditional ROM or SRAM structures for the S
boxes. I am not sure which would be easier to implement - all that
repeated SBOX ROM/SRAM or a pipelined cascade.
As for when one tests, I assume round 16 would not be a great
additional burden on a hardware approach (just about 20% more gates at
most), and would be advantageous in that a variety of approximate key
match criteria could be used to test the result - which would certainly
be important for real world use of such an engine.
But my fundemental point was that by integrating a means of
further testing keys (by decrypting more ciphertext) that matched the
criteria for possible successful decryptions into the individual DES
testing chips themselves one could save a lot of off chip communications
costs - both die real estate and pins on the package - and reduce required
bus bandwidth and support processor latency. This might allow very small
physical packages that would both be cheap and packable in great
quantities onto a card with little added support overhead. Most
previous proposals presumed that additional tests would be done in
software past the initial trial decryption of 8 bytes - this would
require a lot of chip to chip communications and all the baggage in
the form of wide busses and fast interchip communications that this
would entail.
>
> Andreas
>
> P.S.: It's about time to announce this in public. The Chaos Computer
> Club, Berlin, Germany, raises funds to build a DES cracker
> hardware. Of course we won't be doing this unless one or two
> substantial donations by major companies arrive, but we're faithful.
>
Sounds interesting...
Dave Emery
die@die.com
