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

Elektron elektron_rc5 at yahoo.ca
Thu Aug 12 14:24:17 EDT 2004


>> 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 core should be able to return a 'preferred number of iterations', 
but that could just be me.

> 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.

If it's a bug in the core, then it should fail regardless of whether 
the hardware was overclocked or not. If it's due to overclocked 
hardware, it doesn't matter what you do to the core, as errors will 
still happen.

>> 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 client is not CRCd, last time I checked. All you have to do is get 
a decent hex editor and assembly knowledge, and replace one of the 
cores with the interface to the hardware. It should be possible to fit 
it into 1000 instructions.

>> 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.

All blocks are doublechecked anyway. I'm also sure that we give credit 
to duplicate work. We just don't redistribute blocks until all of them 
are already distributed once.

Re-checking is more important in OGR than RC5-72 anyhow. There are two 
possible answers: either "no, there is no better OGR" or "yes, there's 
a better OGR", and both of them could be valid, whereas in RC5 we know 
there's definitely a winning key and can easily check it (unless RSA 
labs is pulling our legs).

- Purr



More information about the Hardware mailing list