Michael, Your point is well taken.
LRW-AES, as it currently stands, does not adequately specify bit orders. This has been discussed, and I think the idea on the table was to change to what GCM uses. The consequence here is that the 'T' value would be bitwise reversed, and yes, the test vectors (along with current implementations of LRW-AES, which all assume 'big-endian' bit order) become outdated. While I understand the objections about implementation of GCM and LRW together, at this point I want to suggest continuing to use 'big-endian' ordering here. Essentially, this is much more intuitive, especially given that our polynomials are representing consecutive integer values (the position value I). I would much prefer to have the 'I' values represented by 0...0001, 0...0002, 0...0003, 0...0004, etc., instead of 8000...0, 4000...0, C000...0, 2000...0, B000...0, etc. Implementing the latter increment in C is awkward. You are correct in saying a consequence of this is that GCM and LRW require different polynomial representations for GF multiplies, and some complications arise in trying to use the same software/circuits for both. Ken -----Original Message----- From: Michael Torla [mailto:[EMAIL PROTECTED] Sent: September 23, 2005 6:48 PM To: Ken Buchanan Cc: [EMAIL PROTECTED] Subject: Re: LRW test vectors Ken, I plugged your latest vectors into my C implementation, and I agree that your vectors are correct, per the current definition of LRW. Further, my C implementation already passed all the vectors supplied in the Oct-2004 revision of "Draft Proposal for Tweakable Narrow-block Encryption." However, you did not address Rob's point. he was concerned that: GCM defines: R = 11100001 || 0^120 and says this represents the polynomial f = 1 + a + a^2 + a^7 + a^128. This seems to imply that the leftmost bit is a^0 and the rightmost bit is a^127. LRW defines: P128(x) = x^128 + x^7 + x^2 + x + 1 Your latest test vectors follow the definition for LRW that I pasted from Rob's email. The result of this is that anybody implementing both LRW and GCM in software will have to either * implement two exactly opposite galois-field multiplication routines or * bitwise reverse each of the 128-bit values into and out of the single galois-field multiplication routine when used for the "other" mode of AES. In a hardware implementation, this means that around the galois field multiplier, a set of multiplexers will have to be available to implement the bitwise reversal. Is that what you really want to do??? thanks, Michael Torla Freescale Semiconductor
