[Hardware] Hardware interface to d.net /counting stats
dan_oetting at uswest.net
Thu Aug 12 13:29:38 EDT 2004
On Aug 12, 2004, at 2:15 AM, david fleischer wrote:
> Already we have a really good startint point (IMHO)
> D.net has written the client software, which seems to
> run very well. They also make the "core" available for
> tinkering, therefore it seems that this is an ideal
> place where to put the interface.
An RC5 cracking engine was implemented in hardware back in 1995 but
since the official clients are closed this hardware cannot contribute
to the project.
Yes, there is an open source version of the client. But some critical
pieces are missing in the open source so a tinkerer cannot build a
client that works with the d.net servers. The tinkerer is expected to
give there core back to d.net to be compiled into an official client.
This will not work for 1000's of hardware tinkerers. It hasn't worked
for 1 hardware tinkerer since 1995.
> We just replace the code that is regarded as the
> "core" with a function that send the starting index of
> the 2^32 key block to the external hardware.
In the current clients the core is not given a 2^32 key block to
process. The blocks are usually broken down into much smaller
fragments. I know for my own soft cores they would run more efficiently
if given a really large block and left running in a separate thread
wheere it doesn't have to start over every few thousand keys.
> The hardware searches the keys and returns the same
> strings as the soft "core" would.
The soft cores return a binary structure. It's not converted into a
string until it gets back to a higher layer in the client. To be
compatible with the current clinets, the hardware needs to return
information that can be converted into the same structure used by the
Currently, the information returned by the core includes:
- The number of partial keys found within a block
- One of the partial keys found
- The number of keys processed
- A flag if the core bailed out early because it thought it found the
This information can all be derived from what I suggested the hardware
cores should return.
I've gone a step further in suggesting that the hardware should return
better information than the soft clients (actually I suggest that the
soft clients should also return this better information).
The residual check allows every bit of the cores work to be checked and
not just the work of one probable key in 2^32. These hardware tinkerers
are going to push their work to the limit and many will go over the
limit. If they are right on the edge and getting one glitch in a
million keys we will probably never see the error unless they process a
million blocks and every block was double checked. But that 1 in a
million shot could still kill the result of the real key.
That 1 in a million glitch would however show up in a residual check in
just about every block. Blocks could be periodically double checked to
keep track of the health of the hardware.
Putting special case tests in the core is dangerous because those tests
cannot be rechecked without duplicating the whole work. What if this
test fails in the RC5 core?
if (B == rc5_72unitwork->cypher.hi)
*iterations -= (kiter + 1);
What's the chance of that happening you might say. In fact it DID
happen in one of the DES cores when running on over clocked hardware on
a hot day after the client had been running for several hours.
Fortunately this one was caught by the developer while running test
blocks threw the new core and watching for errors. If that developer
wasn't so through in testing the core it could have happened to some
kid running the real client on his gaming machine and we would never
have know that the real key was found and vanished in the core.
The hardware to generate that value B accounts for about 2-3% overall.
Software gets to branch around this part most of the time. But you have
to lay out the hardware for everything even if it's almost never used.
Once the partial match keys are found the time to recheck them in
software is insignificant. They can be checked and rechecked and
verified and provide another realtime check on the hardware operation.
> In order to do this the first tiny initial step is to
> document the function declaration of the core, to
> define what IS the interface.
The interface to the core is well know. But you cannot build a working
client for your own core because there are pieces of the operational
client that are kept secret.
> The problem of verification of work done on a block is
> obviously that in order to check it, essentially that
> part of the key space has to be searched again. This
> is perhaps another area where the hardware
> "accelerator" could be useful.
Do we give stats credit to someone rechecking a block that has already
been checked? Does the person rechecking a block have a chance at
winning the prize for finding the real key? Do we want to waste an
extra decade double checking all of the key space?
I don't want to take the project away from d.net. But d.net hasn't
shown any inclination of moving to support open hardware cracking
engines. The best way to get their butts moving is to light a fire
under them. And being prepared to take the project over if they don't
move is the best fire I can think of to set them in motion.
More information about the Hardware