[HARDWARE] Cracking engine wish list

Dan Oetting oetting at gldmutt.cr.usgs.gov
Sat Sep 18 14:33:04 EDT 1999


At 14:05 +0300 9/18/1999, Stelios Koroneos wrote:
>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 already has
>experience in
>designing the comms with remote hosts.

This looks like a good place to reintroduce inline testing. Currently the
d.net clients test themselves once at startup and assume if they pass the
startup tests everything will function perfectly. As we move to dedicated
cracking boxes  there is more opportunity for hardware and software errors
to invalidate the cracking efforts. My inline testing procedure verifies
the proper operation of the client with every block processed. And the best
part about inline testing is it doesn't cut into the cracking rate. The
test for each block can be generated by the master server and the results
verified when the logs are processed so even intentional tampering anywhere
in the distributed network can be detected.

>One last note.
>This is not an effort to make money. Design details should be made
>available for free,
>so if someone wants to make the cracking engine on their own can do it.
>As d.net wants to be sure that the results coming 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.
>After the end of the competition all code can be released to the public.

With inline testing there are no hidden protocols so all code can (and
should) be made public up front.

--
Dan Oetting <dan_oetting at comug.com>

PowerPC 603/604/750 -- Still the fastest RC5 core on the net
(but not for long...)


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



More information about the Hardware mailing list