[Hardware] RC5 with FPGAs
Martin Klingensmith
martin at nnytech.net
Wed Sep 6 14:44:29 EDT 2006
IIRC, you don't need a lot of temporary storage with a pipelined core
because the temporary storage is in the output flip-flops of each stage.
I suppose an interesting project would be a sort of CPU that was highly
optimized for this operation but could do other things as well.
--
Martin
Olivier Meyer wrote:
> What you can do, is run several cores at the same time, if you have
> enough area. That way, a large, slow chip can beat a small, fast chip.
> This can get you a better (key per second)/(cost) ratio.
>
> On 9/6/06, *david fleischer* <cilantro_il at yahoo.com
> <mailto:cilantro_il at yahoo.com>> wrote:
>
> Sounds like a good idea.
>
> > On 9/5/06, Fugu <roguefugu at gmail.com
> <mailto:roguefugu at gmail.com>> wrote:
> > >
> > > By the way, I am also working on a FPGA
> > implementation.
> > > A technique that can accelerate keyspeed is this:
> > > 1) Use pipelining
> > > 2) Have the maximum numbers of decryption engines,
> > as to use all the
> > > gates.
> > > BTW, posting your core on opencores.org <http://opencores.org>
> would
> > enable it to be checked for
> > > bugs and improved.
>
> You can probably add it to your list below as 3)
> Collect optimization parameters for each FPGA device.
>
> By the way, I'm not sure pipelining will bring you
> great benefits in an FPGA. A back of the laptop
> calculation tells me that you'll need approximately
> 1Kbit of memory per key. This may mean that most of
> the archirecture will be shoveling data back and forth
> to the core.
>
> I also have a question, can someone help me figure out
> the code in the source ANSI cores? I cannot understand
> how the key increment is done. (that is to say, I see
> what the code is doing, but I cannot figure out why
> this does any good.)
>
> Code snippet included below:
> #define key rc5_72unitwork->L0
> key.hi = (key.hi + 0x01) & 0x000000FF;
> if (!key.hi)
> {
> key.mid = key.mid + 0x01000000;
> if (!(key.mid & 0xFF000000u))
> {
> key.mid = (key.mid + 0x00010000) & 0x00FFFFFF;
> if (!(key.mid & 0x00FF0000))
> {
> key.mid = (key.mid + 0x00000100) &
> 0x0000FFFF;
> if (!(key.mid & 0x0000FF00))
> {
> key.mid = (key.mid + 0x00000001) &
> 0x000000FF;
> if (!key.mid)
> {
> key.lo = key.lo + 0x01000000;
> if (!(key.lo & 0xFF000000u))
> {
> key.lo = (key.lo + 0x00010000) &
> 0x00FFFFFF;
> if (!( key.lo & 0x00FF0000))
> {
> key.lo = (key.lo + 0x00000100) &
> 0x0000FFFF;
> if (!(key.lo & 0x0000FF00))
> {
> key.lo = (key.lo + 0x00000001) &
> 0x000000FF;
> }
> }
> }
> }
> }
> }
> }
> }
> #undef key
>
>
>
> --- Fugu < roguefugu at gmail.com <mailto:roguefugu at gmail.com>> wrote:
>
> > Doing a quick survey of the hardware list, there
> > seems to be many people(me
> > included), that seem, to various stages, to be
> > dabbling with an FPGA (or
> > other soft silicon) implementation.
> > I hereby propose that we make a central area for
> > such developments, to
> > coordinate development.
> > Another techinical idea: Instead of fine tuning each
> > implementation to each
> > FPGA, we could have one "main" code, and use a core
> > generator program to
> > tune it to each individual FPGA, to allow for
> > maximum optimization.
> >
> >
> > On 9/5/06, Fugu <roguefugu at gmail.com
> <mailto:roguefugu at gmail.com>> wrote:
> > >
> > > By the way, I am also working on a FPGA
> > implementation.
> > > A technique that can accelerate keyspeed is this:
> > > 1) Use pipelining
> > > 2) Have the maximum numbers of decryption engines,
> > as to use all the
> > > gates.
> > > BTW, posting your core on opencores.org <http://opencores.org>
> would
> > enable it to be checked for
> > > bugs and improved.
> > >
> > >
> > > On 6/14/06, Jim C. Nasby <
> > decibel at distributed.net <mailto:decibel at distributed.net> > wrote:
> > > >
> > > > On Wed, Jun 14, 2006 at 03:13:04PM -0600, Fugu
> > wrote:
> > > > > One could do hardware error detection by
> > re-encrypting the "decrypted"
> > > > > message by the same key, and comparing it to
> > the given message.
> > > >
> > > > Yes, but that gives much less protection than
> > checking things on the
> > > > server does.
> > > > --
> > > > Jim C. Nasby, Database Architect
> > decibel at distributed.net <mailto:decibel at distributed.net>
> > > > Give your computer some brain candy!
> > www.distributed.net <http://www.distributed.net> Team #1828
> > > >
> > > > Windows: "Where do you want to go today?"
> > > > Linux: "Where do you want to go tomorrow?"
> > > > FreeBSD: "Are you guys coming, or what?"
> > > > _______________________________________________
> > > > Hardware mailing list
> > > > Hardware at lists.distributed.net
> <mailto:Hardware at lists.distributed.net>
> > > >
> >
> http://lists.distributed.net/mailman/listinfo/hardware
> > > >
> > >
> > >
> > >
> > > --
> > > FIN|ACK
> > >
> >
> >
> >
> > --
> > FIN|ACK
> > > _______________________________________________
> > Hardware mailing list
> > Hardware at lists.distributed.net
> <mailto:Hardware at lists.distributed.net>
> >
> http://lists.distributed.net/mailman/listinfo/hardware
> >
>
> _______________________________________________
> Hardware mailing list
> Hardware at lists.distributed.net <mailto:Hardware at lists.distributed.net>
> http://lists.distributed.net/mailman/listinfo/hardware
>
>
>
>
> --
> -----------------------
> Olivier V. Meyer
> Congress shall make no law respecting an establishment of religion, or
> prohibiting the free exercise thereof; or abridging the freedom of
> speech, or of the press; or the right of the people peaceably to
> assemble, and to petition the government for a redress of grievances.
> ------------------------------------------------------------------------
>
> _______________________________________________
> Hardware mailing list
> Hardware at lists.distributed.net
> http://lists.distributed.net/mailman/listinfo/hardware
>
More information about the Hardware
mailing list