Re: Notes... The case for an open client

On Aug 16, 2004, at 3:24 AM, [email protected] wrote:

> One thing to keep in mind is that with previous projects such as 
> 56-bit DES
> projects, distributed.net had to employ a bitslicing algorithm which 
> caused
> the keyspace to need to be incremented in a non-linear way, even 
> though the
> hexadecimal block numbers displayed by the clients appeared to be 
> linear.
> Similarly when the DES success indicator was sent by the correct dnetc
> client, the block id that was included had to be "translated" into the
> normal DES key format using proper bit ordering and parity bits.  This
> aspect would have made it very difficult for a competing effort to
> successfully avoid the "d.net wake" unless they were also using the 
> same
> bitslicing algorithm.  (Fortunately RC5 is not that way.)

Except for the Byte reversals! At the start of RC5-64 there were at 
least 3 competing projects that had been working RC5-56 
non-cooperatively. A plan was developed to share the key space but then 
it was discovered that the other projects were incrementing keys in a 
fashion that could not avoid overlaps.

The d.net key increment order in RC5 is still not the most efficient. I 
was able to absorb the overhead of reverse byte increments in the 
PowerPC cores but other platforms probably didn't fair so well. At 
least in RC5-72 there is enough space so a project using reverse word 
incrementing in the clients can still share the key space with d.net.

In serial bit-stream hardware cores the reversed byte increments will 
be tricky. A linear increment of the middle word would be easiest 
(after incrementing through 8 bits of the high word). The individual 
work units from this hardware core would not be compatible with d.net 
but a block of 256 could be converted.

After processing 40 bits of the key space, where does the hardware core 
go next? Some hardware cores may get programmed with a starting key and 
crank out blocks in some order until they get shut down. To follow the 
d.net key space, the core would need to increment the low word in byte 
reversed order. But the easiest for the hardware might be to increment 
the high 24 bits of the low word in linear order leaving the low 8 bits 
for division of the key space between projects.

Maybe a trick can be found to handle byte reversed increments in all 
hardware cores. This is a "key" issue that needs to be resolved before 
the hardware project can move forward. Once the key order is sorted out 
we will be ready to turn on the hardware. Key servers or interfacing 
with d.net can actually come later as long as the output from the 
hardware cores is safely recorded. Such is the advantage of being open.

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