[HARDWARE] Working on a VHDL design

Dan Oetting oetting at gldmutt.cr.usgs.gov
Thu Jan 20 12:44:16 EST 2000


At 10:35 -0700 1/20/2000, John Price wrote:

>What I would like is for you folks to look at it and tell me if there is
>other optimizations that I am missing, or point me to any sources for
>reducing the RC5 algorithm.

Most of the optimizations at this level depend on the hardware. For
instance, if you need to compute values for A+B and A+B+C you would
probably be tempted to first compute A+B and use that value to compute
(A+B)+C. But if you have the hardware that allows you to do two additions
in parallel it may be more efficient to first compute B+C so you can
compute both A+(B+C) and A+B together.

Have you found all the constant sub-expressions in the loop? There are more
if you look at what doesn't change when only the high word of the key is
changed.

There are also a few calculations that you don't need to do most of the
time if you encrypt instead of decrypt but this would preclude using the
engine to crack codes where you only have partial knowledge of the plain
text.

Another big source of optimization is to look at the overall problem you
are trying to solve. The current RC5 effort is designed to crack a single
code. Since the key setup is a significant portion of RC5 you could
probably crack 10 codes in parallel in less than twice the time with the
same hardware.

>I'm also interested in any other hardware implementations.

I've found that Motorola's G4 makes a pretty good hardware implementation. 8^)

>I've studied Paul Campbell's design, but I can't see how it works (it
>doesn't seem to follow the algorithm), but as I said before, I don't know
>Verilog, so excuse my ignorance.
>
>Anyway, my code it attached.  All my code will also be placed on my web
>page at http://www.gcfl.net/projects/rc5/ .



-- Dan Oetting <oetting at ghtmail.cr.usgs.gov>


--
To unsubscribe, send 'unsubscribe hardware' to majordomo at lists.distributed.net



More information about the Hardware mailing list