[HARDWARE] Cracking engine wish list

William J [on the road] Halverson william at netpros.net
Sat Sep 18 12:02:24 EDT 1999

Stelios Koroneos wrote:

> Greetings,
> Based on the e-mails i received and the replies to the list a cracking engine should have
> the following for people to use it
> Price-Performance ratio  = <100$/1Mkeys
> Serial interface (Easy to hook to existing platforms)
> Expandability (Connect more devices in parallel or in a chain)
> Small form factor (size)
> The ability for the device to be re-programmed by the end user is not so high on the wish
> list
> This can be because at this price range more people are willing to "boost" their cracking
> performance with little or no work (Plug and Crack :-)

Seems true ... but I come back to other distributed projects like SETI.  Is it possible that
d.net and projects like SETI could agree on something like this:

"OK, we will support FPGA xxx and yyy and zzz" so here are the images for our projects on
those chips"

In a way , this is just an extension [may be a big one] to the notion of having clients
complied for differnent
CPUS which is how it's done today.


> It seems that the only possible sollution would be an mcu+fpga hybrid system.
> The mcu would handle protocol/communiaction issues with the client soft and even do
> pre-processing for the fpga (create the key table maybe). This way the fpga can have a
> lower gate count and cost.

> In order to get support from d.net a working prototype must be presented first.
> To do this we need the following
> 1. Protocol definition
> We need to define what will be the sequence of communication between the host client soft
> and the cracking engine(s). I think someone from d.net would be more appropriate to have
> a first look at this and propose a possible protocol. D.net allready has experience in
> designing the comms with remote hosts.
> 2. Decide which part of the rc5 code should be in the fpga and what part in the mcu
> This would clarify the design goals and specs  both for the mcu and the fpga
> People who have coded clients/implementations (in soft or hardware) of the RC5 can help
> in this stage to decide which part of the code need to be implemented in which part.
> 3. Design the mcu and fpga "programs"
> As far as i know there are several "public" fpga cores for a number of encryption
> standards. Contacting the authors and requesting their help migh be the most appropriate
> as it will save time and costs.
> 4. Implementing a working prototype and checking it...
> Well it sounds easy on "paper" (or bytes more appropriate) but are there any people who
> are willing to put their code/efforts to do domething like this ?
> I can help with the mcu part, but more people are need it if we want to do something in a
> relative short time (3-6 months)
> One last note.
> This is not an effort to make money. Design details should be made availiable for free,
> so if someone wants to make the cracking engine on their own can do it.

Agreed on my part.  Maybe the right approach is a kit or plans?

> As d.net wants to be sure that the results comming out from this design are correct,
> maybe it will be necessary not to publish the fpga code or the mcu code and provide
> programmed mcu/fpga at cost  to people who want to make their own engine.

Good idea.  The FPGA can be tested/certified and installed by the cracker into his self-built
The code will be able to tell d.net 'yes, these results are correct'.

> After the end of the competition all code can be released to the public.

Hmmmm .... d.net code or dsigner code??  If a designer thinks he's got something patentable

Bill Halverson

To unsubscribe, send 'unsubscribe hardware' to majordomo at lists.distributed.net

More information about the Hardware mailing list