Re: [P1619-2] XCB-AES text for .2 draft
Earlier we discussed the possibility of different groups implementing
our proposed cipher modes so that we can compare test vectors. I
already have an implementation of EME2 based on Shai Halevi's original
EME code. Recently I tried implementing XCB based on the draft posted
here.
Mostly it was pretty clear but there were a number of typos and places
where I was confused, which I want to list.
Page 1: "When encrypting a tweak value using AES, the tweak is first
converted into a little-endian byte array." However, I never found it
necessary to encrypt a tweak value using AES.
Page 1: "The function len(S) returns a w/2-bit string containing the
nonnegative integer describing the number of bits in its argument S,
with the least significant bit on the right." At this point w has not
been defined, but later it becomes clear that it is the block size of
the underlying cipher, or 128 in the case of AES.
Page 2: "The function c : {0, 1}k × {0, 1}128 → {0, 1}l..." at this
point k has not been defined, but it becomes clear that it is the key
size for the cipher, either 128 or 256 for XCB-AES.
Page 2: "h1 (H, Z, B) = h(H, 0128||Z,B||0#B mod 256)" [I know this is
not really printing right, it is what I get with copy and paste.] I
think instead of #B mod 256 bits of zeros, you want enough 0's to pad
B to a multiple of 256 bits in length. And actually from glancing at
the security proof in the eprint paper at
http://eprint.iacr.org/2007/298 , I think what you want is enough 0's
to pad B to a multiple of 128 bits in length, followed by 128 bits of
zeros. That way h1 and h2 will be the same length.
Page 2: "h2 (H, Z, B) = h(H, Z||0,E||0||len(Z||L)||len(B))" This has a
superscript 128 on Z which I don't think is supposed to be there, and
refers to E when I think it means B. Or perhaps you would prefer to
change the B's to E, since that is how it is actually used. The
padding on E (or B) is again I think supposed to be enough bits to
make it a multiple of 128, not #B mod 128. And there is the mysterious
"L", which I can't find anywhere. Looking at the eprint paper,
equation 8 and figure 1 appear to use 128 bits of zeros in place of L.
So I treated len(Z||L) as len(Z)+128. I don't know if it is important
to add this 128, it seems a bit non-functional. But maybe the security
proof depends on it?
Page 2: "h : {0, 1}128 × {0, 1}m × {0, 1}n → {0, 1}128" This
description is pretty confused on its use of index variables; m and n
here look like numbers of bits, but later like numbers of blocks. And
there is A* and C*, and v, which are not too well defined. However the
general thrust is reasonably clear, you hash in the blocks of A,
zero-padding the last one, then the blocks of C, the same way, then
finally the 128 bit block composed of two 64-bit bit lengths of A and
C.
I found it a little tricky to cleanly implement h1 and h2 in terms of
h because of the need to prepend or append a 128 bit block of zeros to
the variable length tweak Z. I refactored it a little and got
something that worked OK, but in the process I noticed that prepending
a block of zeros doesn't do anything at all to the calculation until
the very last step, when we use the length of A. That length has
increased by 128, and that's the only change. I guess that this is OK
as it is accounted for in the security proof.
One other thing that was a little unclear was what to do if A or C
were an exact multiple of 128 bits, whether they should be padded with
a full 128 bits of zeros or no padding at all. I assumed the latter
since I don't see any point in the zeros.
Page 4: "F ← AES-enc(Ke,A)... A ← AES-dec(Kd,F)" These steps in the
decryption function should have Ke and Kd reversed.
For what it's worth, with these interpretations, if I use a 128 bit
key of all zeros, a 128 bit tweak of all zeros, and encrypt a 512 byte
disk block of all zeros, the first 16 bytes of the output are: 91 58
A4 DF 1A F0 C5 85 E4 59 85 F9 26 E2 D6 AD. Probably a little premature
even to mention this but it would be interesting if it matched other
people's values.
Hal Finney
PGP Corporation