> From: [EMAIL PROTECTED] > [...] > The HW development, debug time; the extra infrastructure to manage the > third keys: [...]
When discussing the interfaces of LRW to the outside world, we should NEVER think about LRW as having more than one key. It always has just one key (of somewhere between 32 and 64 bytes). The fact that it uses different parts of that key in different ways should not be visible from outside. Doing otherwise is an invitation for troubles. In particular, you don't "manage the third key", you just manage keys that are longer than before. > From: Colin Sinclair > [...] > Changing to K2.(1<<j) is just silly; an optimised implementation using > tables would have to store 32 K2 > partial products rather than the 5 currently needed (1,3,7,15,31). Colin, you are missing the point here. An optimized implementation will not have to store ANY tables at all. If you already computed K*I, then computing K*(2I)=2*(K*I) takes one shift and one conditional xor. This is to be compared to the 5-value table that is needed in the current proposal for the range I \in 0..31, 6-value table for the range 0..63, etc. That being said, I don't care much for this argument. I proposed that alternative so that implementers can look at it and see if they like it. It can probably give you somewhat better performance in most environments than the current proposal, but the difference is not large and perhaps it is not worth the bandwidth that we already spent on it. > From: Matt Ball > [...] > Sorry for the long e-mail, but there are some important security > issues with LRW that we need to look at before finalizing the > standard. [..] I strongly disagree that these are security issues. LRW (like pretty much every crypto algorithm) needs random keys. If you use it with keys that are not random, you deserve what's coming to you. There are many established ways to derive cryptographic keys, and all of them are adequate also for LRW. -- Shai
