[Hardware] Hardware interface to d.net /counting stats
dan_oetting at uswest.net
Wed Aug 11 12:53:42 EDT 2004
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
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.
More information about the Hardware