Re: [P1619-2] EME-2 definition/choice of M1 in middle layer mask update
Yes, I see the consequences of M1 cropping up in several places in the
proof, which is way over my head. I am sure that there are multiple
possibilibilites for extending the mask generation which hold up well under
scrutiny. But as I realised, I now see no reason to request any change,
there is no additional hardware overhead implied.
If I had more recently read the 2nd paragraph of Appendix A of the original
EME paper (2003/147.pdf), which explains very clearly how the extension is
formulated, I'd probably not have made the mistake.
BTW, it's mildly interesting to note that the reason you couldn't reuse
"SP/SC xor T" as the value to add for subsequent mask generation either side
of the middle layer block cipher is because you would get the same
cancellation scenario I pointed out a couple of weeks ago, but for block
PPP_129 not PPP_1. Using M1 is the natural choice but is more interesting
because it does actually result in PPP_129 cancelling out in MP2 (and
therefore MC2), but the contribution from PPP_129 in M1 gets added back in
after the cipher to appear in CCC_129. So, PPP_129 /looks/ like it goes
through the middle layer cipher, but actually it hops over it via SP, MP1
and M1. Had you considered/noticed this at all in your choice of M1?
Finally, I'll just reiterate that, from a standards viewpoint, the test
vector coverage is not good enough, because the longest 2065 bytes vector
does not test Mi computation or usage for i >= 2, which is different to the
i=1 computation. It is /necessary/ to have a 258.x block vector to get full
coverage of the branches of the algorithm.
Regards,
Colin.
> -----Original Message-----
> From: Shai Halevi [mailto:shaih@xxxxxxxxxxxx]
> Sent: 04 February 2010 15:56
> To: P1619-2@xxxxxxxxxxxxxxxxx
> Subject: Re: [P1619-2] P1619.2 Recirculation Ballot has now started
>
>
> > Shai, any chance you can redefine this to be M(i-1) not M1 without
> > compromising the security proof???
>
> Very good question, I don't really know the answer.
>
> I remember that there was some reason that made it easier to prove
> security when using M1 everywhere. (I think that this is used in
> Claim 14 on page 30 of the ePrint version, not 100% sure about it.)
>
> I was never sure about this being really necessary (i.e., I don't know
> of any attack that would be possible otherwise), but using M(i-1) would
> mean adding a new bunch of special cases to consider in the proof. It
> is certainly plausible that one can analyze these new special cases and
> verify that none of them cause a problem. It is also plausible that
> one of them will turn out to be an attack.
>
> I'm guessing that it would be easier to add a comment saying "yes we
> really mean M1", than to change the mode.
>
> -- Shai