Hardware interface to d.net /counting stats

There is still a serious hurdle to overcome in interfacing the custom 
hardware cracking engines to the closed d.net clients and servers. 
Instead of trying to join them why not ask them to join you.

If you can crack a significant fraction of their key rate you can 
easily undercut their efforts. Just  run a network of small spy clients 
to track the key space they are working on and run your hardware on the 
space in front of them. Since you have significantly lower (almost 
zero) latencies you can easily beat them to the prize. Active 
disruption by running bogus clients can create a force multiplier to 
your advantage because you will know what key space they missed and can 
scan it in a second pass while they waist time rescanning the entire 
key space.

So how do you get them to cooperate? I would think they would want to 
avoid the above scenario, especially with a serious contender. And they 
have shown a willingness to cooperate with other groups in the past. 
When RC5-64 started (or was it 56?) there were at least 3 separate 
groups running distributed clients and d.net agreed to divide the key 
space so they would all work on different segments without overlapping 
and wasting effort. In the DES-II and DES-III challenges EFF's Deep 
Crack was as fast as all of d.net and they combined forces to assault 
the cypher in under 4 hours.

When you have the hardware built, tested and ready to go, just ask 
d.net for a block of 2^64 keys to run on your hardware. When you have 
that much power you don't need their stats page for fame. You can 
publish your own stats.

There is on average 1 false positive key in every 2^64 block. 
Publishing these keys will be positive proof that you really processed 
those blocks and didn't just pretend to have the hardware.


For the smaller hardware experimenters, each key found that properly 
encrypts the first 32 bits of text should count for 1 block processed. 
There would be no incentive to cut corners and stop processing a block 
when the first partial key is found because every key has an equal 
probability of being a partial key. It does allow the hardware to shave 
off about 2-3% of the work because the last half of the cypher text 
isn't used. There can be multiple keys back to back so the hardware 
should be tested to be sure it can handle such a case. A residual check 
is important for verification of proper hardware operation. The 
residual should be something simple like a 32 bit sum of the first 32 
bits of the encrypted text of every key tested. It costs a fraction of 
what is saved by shaving off the last 32 bits.

The clients don't even need to be told what the last 32 bits of cypher 
text is. If they don't have a test for the special case of finding the 
real key it is impossible for them to screw it up! We will see in the 
stats if a client appears to be missing partial keys and be able to 
retest those blocks to find out if the hardware is failing.

The clients should return 2 separate status messages back to the 
servers. The first message returns the partial keys found (1 or more 
per message). The second message returns the key space processed, the 
number of partial keys found within that space and the residual check 
for the space. Stats credit should be given for the number of verified 
partial keys found (message 1) within a key space reported as processed 
(message 2). A personal proxy can divide a block of key space to 
multiple clients regroup the results and verify that a block is 
completed in a reasonable time. A personal proxy looks a lot like a 
driver for a hardware cracking engine. Since there is nothing to hide 
and the work units counted for stats would all be self verifying, all 
the code can and should be open.

_______________________________________________
Hardware mailing list
Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/hardware