Re: Hardware interface to d.net /counting stats

On Aug 11, 2004, at 4:19 PM, jbass-/[email protected] wrote:

> "Dan Oetting" <[email protected]> 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 
> engines.
> 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 
remaining bits.

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.


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