[Hardware] Hardware interface to d.net /counting stats

Dan Oetting 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 
soft cores.

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 
winning key

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);
         return RESULT_FOUND;
       }

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 mailing list