[Hardware] RC5 with FPGAs
david fleischer
cilantro_il at yahoo.com
Wed Sep 6 14:07:38 EDT 2006
Sounds like a good idea.
> On 9/5/06, Fugu <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 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> 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> 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 would
> enable it to be checked for
> > bugs and improved.
> >
> >
> > On 6/14/06, Jim C. Nasby <
> 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
> > > Give your computer some brain candy!
> 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
> > >
>
http://lists.distributed.net/mailman/listinfo/hardware
> > >
> >
> >
> >
> > --
> > FIN|ACK
> >
>
>
>
> --
> FIN|ACK
> > _______________________________________________
> Hardware mailing list
> Hardware at lists.distributed.net
>
http://lists.distributed.net/mailman/listinfo/hardware
>
More information about the Hardware
mailing list