Re: RC5 with FPGAs

Such implementations have been discussed heavily in this forum. The  
last word was that d.net is more than willing to share the key-space  
with hardware engines. The primary requirement in order to work  
together is that the hardware engine must increment keys in the same  
order as the d.net client.

Until there is a substantial deployment of hardware cracking engines  
there probably won't be automatic key distribution for them. But the  
d.net officials can reserve a block for you to process using manually  
entry.

An important consideration for hardware cracking engines is detection  
of errors. When pushing the limits of the hardware or in large  
projects it is very easy to drop a bit and never notice. A 1 bit  
error in the RC5 computation could cause the winning key to be  
missed. Random bit errors are most easily detected by computing a  
checksum for the encryption results of a block of keys then  
reprocessing that same block at a later time or on other hardware.

A critical error that has shown up in d.net cracking cores while  
testing new software is a failure to detect that the encryption  
result matches the target result. This was a real eye opener because  
it was a worst possible case and only happened to be spotted by the  
programmer developing the code. The bug was due to a combination of  
over-clocked hardware and high CPU temperatures and only showed up  
with certain data patterns so it could easily be missed in normal  
testing.

To catch errors like this in the field and to allow open client  
software I have been pushing for an alternate method of reporting  
work processed. The proposal is to search for specific partial  
matches to the target encryption result. These partial matches are  
randomly distributed in the key space and can only be found by  
searching. Each partial match can be instantly verified so they  
cannot be forged. Clients or hardware that is mis-behaving will miss  
valid matches which will show up as a statistical deficit or will  
report erroneous matches. Clients on average would receive the same  
credit as they would by reporting blocks processed but there is no  
way to falsify the work report.

Searching for partial matches requires only minor changes to the  
encryption engine but it can present difficulties in getting the  
results out of the chip.

-- Dan Oetting



On May 16, 2006, at 10:26 AM, [email protected] wrote:

> Hello,
>
> I hope I will have more echoes using the hardware mailing list.
>
> I'm Guerric Meurice de Dormale and I'm a Ph.D. Student at the
> UCL CryptoGroup (Belgium) under the supervision of Jean-Jacques
> Quisquater.
> One of our Ms.C. Student is currently finishing the implementation the
> RC5 32/12/9 challenge on an FPGA platform. It is a fully pipelined  
> design
> with a throughput of one key search every clock cycle.
> Currently, the engine should goes up to 150M keys/sec on a Xilinx
> VirtexII6000-5 device. In the future, it is planned to use Virtex4LX
> FPGAs with a higher logic density and a higher maximum operating
> frequency (a twofold improvement about the frequency is expected (?)).
>
> It could be very valuable for the work of our student to join the
> distributed.net cracking effort. However, as the communication
> protocol is not available, it is not possible without your support.
> Nevertheless, it seems that people were planning to enable FPGA engine
> within the key search effort (cfr. Hardware mailing list). Does
> someone know if something was done in that area? or if something  
> could be
> done?
>
> I already thank you for reading this email.
> I hope we could join distributed.net soon!
>
> -- 
> Best regards,
> Guerric Meurice de Dormale
> Ph.D. Student
> UCL DICE/Crypto Group
> http://www.dice.ucl.ac.be/crypto/
>
>
> _______________________________________________
> Hardware mailing list
> Hardware-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
> http://lists.distributed.net/mailman/listinfo/hardware
>

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