[Hardware] Notes... The case for an open client
elektron_rc5 at yahoo.ca
Mon Aug 16 13:58:49 EDT 2004
>> Byte-reversed adds are easy. You just wire the carry bits differently.
> That works if you are doing adds as 32 bit words. For a serial bit
> stream you have the bits in one order for the increment then they get
> chopped up and reordered before feeding in as the initial L values of
> the first round. Feeding through something like a barrel shifter or
> breaking each word into 4 individual bytes would probably work but
> it's still a little extra overhead.
> Do we accept the extra overhead for compatibility or find the easiest
> possible implementation for the cores? Adaption of the software cores
> to join the hardware project will be relatively easy and may even make
> them faster.
What's preventing us from switching from byte-reversed to
non-byte-reversed? (Why the hell is it byte-reversed anyway? Is it
advantageous to do strange things to the key?)
Also, isn't it possible to recode the client to internally not bother
(much) with byte-reverse adds (until it overflows by 2^32)? Aren't all
blocks 2^32, at the moment, anyway? (I don't see an option for it)
The core should also be able to tell the client its own MIN_ITERATIONS
(anyone fancy a 5-pipe?), recommended iterations (for cores which may
have large init overheads), and any necessary alignment (as a power of
I'm not sure how 1-bit-serial hardware is supposed to work.
More information about the Hardware