[Hardware] Hardware interface to d.net /counting stats
dan_oetting at uswest.net
Thu Aug 12 00:13:24 EDT 2004
On Aug 11, 2004, at 4:19 PM, jbass at dmsd.com wrote:
> "Dan Oetting" <dan_oetting at uswest.net> writes:
>> 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 are enough small FPGA's out in the world in the form of student
> FPGA boards. Those hung off a parallel port would make modest RC5
> A few thousand of those thruout the d.net community, would bump the
> key rate significantly.
> So the hardware *IS* built, just need software to drive it.
Ok, lets do it.
The first thing to do is define what the client (hardware or software)
must do. I'll list what I think will work for a starting point and we
can discuss the alternatives and merits.
The hardware is going to be open. There is no way around it so we might
as well make the client that drives the hardware open too. There can be
a level at which public proxies and servers are closed but that is far
enough from the hardware that it won't be a design limitation.
Wether d.net runs the servers for the hardware cracking network or not
it would be nice to not overlap their work. That means whatever d.net
is using for the outermost blocks will also be our outermost block.
Work units will consist of a consecutive range of keys to be processed
with some minimum resolution (such as 2^32 keys). This is to give core
designers the ability to optimize if they know they can count on a full
cycle of 2^32 keys say for massively parallel designs where certain key
bits are constants within each element. Because work units could be
larger than 2^32 keys the order of the key bits above the first 32 will
be defined so it is known how to count from the first block through the
last block in the work unit.
Work units will also contain the first 64 bits of plain text and the
first 32 bits of cypher text. I know we will probably be crunching the
same RC5-72 cypher for the next decade or two but being able to load a
different set of texts allows the core to be tested for extreme cases.
Clients will return every "partial" key that generates an encrypted
text that matches the first 32 bits of the provided cypher text. These
keys will be verified and tested for the elusive "true key" by the
master server (or a trusted secondary server). Valid partial keys will
be the counted token for stats and be considered equivalent to
processing a block of 2^32 keys for stats purposes.
Clients will also return a residual check for each block processed and
the number of partial keys found within the block. The residual check
will be computed as a 32 bit sum of the first 32 bits of the cypher
text generated by each key in the block.
And that's it.
Except there will be something about client id's used for tracking and
assigning stats but that won't affect the hardware core.
I guess the first things to nail down are: Exactly which bits in the
key define the minimum resolution block. Which bits define the space to
split work allocations between the current d.net project and the
hardware cracking network. And define the significance order of the
Returning a residual for every block of 2^32 keys and a partial key on
average of 1 in 2^32 keys may be too much data for the servers. If so,
the client or a proxy could reduce the data before it goes to the
servers. The question that needs to be answered is will this be too
much data to pull out of a hardware cracking engine? Keep in mind that
hardware will be getting faster over the next two decades in the life
of this project.
More information about the Hardware