[1129] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Better DES challenge update

daemon@ATHENA.MIT.EDU (Dave Emery)
Sun Jun 29 21:24:45 1997

From: Dave Emery <die@pig.die.com>
In-Reply-To: <199706290410.VAA26082@blacklodge.c2.net> from "Eli Brandt" at "Jun 29, 97 00:10:00 am"
To: eli@gs160.sp.cs.cmu.edu (Eli Brandt)
Date: Sun, 29 Jun 1997 20:32:58 -0400 (EDT)
Cc: cryptography@c2.net, crisp@netcom.com (Richard Crisp)
Reply-To: die@die.com

Eli Brandt wrote :

> Okay, so maybe I'm getting a bit ahead of myself.  How much design work
> would have to be done first?

	The efficient way to build such a machine is using a deeply
pipelined compiled ASIC in say .35 micron or so.  This could easily do
at least one key a clock and be clocked at 200 to 300 mhz (eg 1 key
every 3-5 ns).

	As I see such an architecture, the ASIC would either contain a
second slow DES path (more or less similar to a current DES chip and not
pipelined like the main engine) or logic to insert out of order keys
into the main pipelined engine.  This would allow the chip to buffer in
a FIFO and asynchronously test hits on possible keys to any reasonable
desired depth without going off chip. This architecture would allow keys
that produced all zeros or ones or correct parity in the decoded data
parity bits ( or any of the other proposed hardware mask and XOR and
test for 0 type tests for an interesting key) to be tested further in
hardware on chip by decoding (much more slowly) another 8 bytes or even
16 bytes and would reduce the housekeeping for  key hits required of the
controlling intelligence to a low enough value so a simple 8 bit
bidirectional bus could be used to coordinate and control the chip. 
Doing this would reduce the pin count a lot, and the chip area required
for bonding pads and drivers, and might enable the chip to be put in a
very small footprint package (depending on thermal considerations). The
smaller the footprint and die size, the cheaper the chip and the more
one could put on a given board. And with only hits that matched on 16 or
24 or even 32 bytes to handle in software on a supervisor processor, a
signle supervisor could handle many chips (a full rack of VME boards
full for example).

	Current EDA tools would design such a chip just fine, but of
course they cost upwards of multiple tens of thousands per seat and such
a project would therefore almost certainly require the cooperation of a
company or university that had access to a modern tool suite.   My guess
is that an experianced digital engineer familiar with the tools could
grind something out and simulate it in a two or three months of work. 
Fully qualifying it for a foundary might cost another 3 months.  (I will
have to ask my chip hacker friends for a more precise estimate...). This
of course assumes compiled logic specified in VHDL rather than hand
design at the gate level.

	I suppose the chip might cost around $75-100K to fabricate in
prototype quantities of a few hundred.  (Again I can ask some
people who do this for a living ...). Subsequent runs would be
much cheaper per chip...

	So I guess one might figure an upfront NRE of around O(100K)
if the actual design time was donated for the most part, and possibly
as little as $20-30/per chip installed in a system in quantity with
each chip able to do 2*10e8 keys per second.  Paying consulting rates
to people who were doing this to earn money could easily run to 
another couple of hundred K... but there may be some interest amoung
chip hackers out there...


						Dave Emery
						die@die.com
						Weston, Mass.
	


home help back first fref pref prev next nref lref last post