Re: RC5 with FPGAs

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-/[email protected]> wrote:
>
> Sounds like a good idea.
>
> > On 9/5/06, Fugu <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <
> > [email protected]> 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
> > [email protected]
> > > > 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-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
> > > >
> >
> http://lists.distributed.net/mailman/listinfo/hardware
> > > >
> > >
> > >
> > >
> > > --
> > > FIN|ACK
> > >
> >
> >
> >
> > --
> > FIN|ACK
> > > _______________________________________________
> > 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
>



-- 
-----------------------
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-Ra3b/QYEcJ3d140v2zMXi0fjHoOT/h/[email protected]
http://lists.distributed.net/mailman/listinfo/hardware