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

david fleischer cilantro_il at yahoo.com
Thu Aug 12 04:15:07 EDT 2004

Already we have a really good startint point (IMHO)
D.net has written the client software, which seems to
run very well. They also make the "core" available for
tinkering, therefore it seems that this is an ideal
place where to put the interface.
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.
The hardware searches the keys and returns the same
strings as the soft "core" would.
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 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.


--- Dan Oetting <dan_oetting at uswest.net> wrote:

> On Aug 11, 2004, at 4:19 PM, jbass at dmsd.com wrote:
> > 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 at lists.distributed.net

More information about the Hardware mailing list