[Hardware] The market of ASICs (One GigaKey / Second?)

david fleischer cilantro_il at yahoo.com
Sun Aug 8 03:07:04 EDT 2004

Thanks, that's more like it ! 
I will still have to go through the code to understand
how it matches the algorithm... some of us (hard) are
just not the programming type.
The key question for me is, what is the interface? how
does the program talk to the part that does the
numerical computation. 
Also, before I jump and get wet with FIFOs and adders;
which are the functional parts of the core? From what
I understand there is a 'key table' generation step
and a decrypting stage proper. Because in this project
we're testing keys on only a few bytes, I suspect that
the key table generation will be a significant portion
of the computation.

> On Aug 7, 2004, at 3:24 PM, jbass at dmsd.com wrote:
> > "Dan Oetting" <dan_oetting at uswest.net> writes:
> >> What type of analysis are you looking for? One of
> the first thing I 
> >> did
> >> when starting to work on optimizing the cores was
> build a simple
> >> reference core to understand what was going on.
> Here is my RC5-64
> >> reference core. The only major change for RC5-72
> is the key and L[ ]
> >> need to be 3 words (big enough to hold 72 bits)
> instead of 2 and the
> >> index j in the inner loop needs to cycle
> 0,1,2,0,1,2... This should
> >> give you an idea of what the hardware needs to
> do.
> >
> > [ ... sample code deleted ...]
> >
> > That form while it's a direct expression of the
> algorithm, is
> > horrible from both a software and hardware
> performance point of
> > view.
> The reference is exactly that, a direct expression
> of the algorithm. I 
> used this reference extensively when designing my
> own optimized cores. 
> Prints can be inserted to generate a table of all
> the intermediate 
> results for a given input which can be invaluable
> while single stepping 
> through the optimized assembly core looking for that
> elusive typo. The 
> reference can be used to generate the cypher text
> for any key and plain 
> text and built into an automated test generator for
> validating the 
> optimized cores. And a modified version of the
> reference can be used to 
> search for adjacent partial results to test a very
> critical but often 
> overlooked piece of the logic in parallel cores.
> All the unrolling and optimizations are simply
> mechanical operations 
> that tend to obfuscate. It sounded like the original
> poster wanted to 
> know what the algorithm was so he could wrap his
> head around it. The 
> optimized source code apparently only confused him.

More information about the Hardware mailing list