Hi,
actually I think Laszlo (or his engineer) has stumbled on something here...
I went through this with a fine toothcomb recently
and I didn't see this subtlety, so my first implementation would be wrong too!
Laszlo's specific question is about line 29, but actually there is an issue
concerning lines 26,28 & 29 which is slightly more
important.
Looking at figure 2 the "suggestion" is that the
first 128 blocks use M1, the second 128 use M2, etc, and that the value of "M"
used in the special case updating on each 128th block is the previous Mi (as
defined on line 7 of page 9). Effectively, I was
(unwittingly and erroneously) going to modify and reorder the computation
thus:
|
26. MP =
PPPi xor M (I use old
Mi)
27. MC =
AES-Enc(KAES, MP)
29. CCCj =
MC xor M (I use old
Mi)
28. M =
MP xor MC
(this is new
Mi) |
But on lines 26 & 29 of both procedures I can now
see it says specifically M1, not M(i-1), which agrees with Shai's statement.
This is a *real* shame, because this now needs special case storage for M1 as
well as a working register for Mi. It's already bad enough having to make
a very special case for MM, but this is another unfortunate algorithm design
decision which makes hardware implementation less attractive
:-(
The
pseudo-code appears to be correct according to Shai's intentions, but figure 2
suggests (by omission) that M1 might be M2 on the next 128th
(ie 256th) block. Unfortunately none of the published test vectors are
long enough to discover such a misinterpretation, since they don't go as
far as the 257th block (> 4K bytes) where a difference between M1 and Mi
would be noticed. Perhaps if it said "M1(always)" in two places
on figure 2, it'd be a lot clearer!
Shai, any chance you can redefine this to be M(i-1)
not M1 without compromising the security proof???
Regards,
Colin.
A question I received about the last draft:
The EME2 code shows in
line 29 (page 10)
PPPj = MP xor M1
Do we have to always use
M1? The engineer thought it was a typo, M1 should be M. The case could be
different from Line 26.