[Hardware] RC5 with FPGAs
dan_oetting at qwest.net
Sat May 27 22:28:19 EDT 2006
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
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
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, gmeurice at dice.ucl.ac.be wrote:
> 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
> 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
> 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
> 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
> Hardware mailing list
> Hardware at lists.distributed.net
More information about the Hardware