Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" as a CFRG document ---- Some clarifications

[Thomas Peyrin <[e-mail]>]

Indeed, if the goal is to have an AES-based AEAD candidate that offers some
kind of misuse resistance, there are quite a few among the CAESAR designs
(AEZ being indeed on of them)

2016-04-20 23:59 GMT+08:00 Adam Langley <[e-mail]>:

> On Wed, Apr 20, 2016 at 2:04 AM, Thomas Peyrin <[e-mail]>
> wrote:
> > I understand the explanations for the first point (considering an AEAD
> now
> > doesn't preclude from having CAESAR candidates later as well), but I
> don't
> > understand for the second point. Why do we need to wait for the end of
> > CAESAR competition before considering CAESAR candidates instead of
> > AES-GCM-SIV ? I believe we should at least take a short look at the
> current
> > algorithms available now, and not only AES-GCM-SIV ?
>
> Many CAESAR candidates may be "better designed" in the same way that
> XSalsa20-Poly1305 is, in some sense, "better designed" than
> AES-GCM-SIV: i.e. it uses operations that are independently useful on
> CPUs and so more performant (with fewer tricks) than the binary fields
> of AES and GHASH/POLYVAL.
>
> But dedicated hardware for AES-GCM is now fairly common in many
> environments and it's very hard for anything to beat the performance
> and power efficiency of this dedicated hardware. (Which seems a little
> like cheating, but that's where we are.)
>
> Thus AES-GCM is the default for encrypting large amounts of data. But
> in situations where a counter nonce isn't possible a significant
> amount of worry has to go into convincing ourselves that a duplicate
> nonce isn't possible. So what we want is AES-GCM—but with less worry.
> Same underlying primitives, basically the same speed, same API, but no
> detonation if nonce uniqueness slips for some crazy reason.
>
> Since this is so so closely related to AES-GCM, I don't think that
> volumes of analysis can be directly compared with CAESAR candidates:
> AES is nearly axiomatic now and so doesn't need the sorts of analysis
> that something like NORX warrants.
>
> I know that some CAESAR candidates are based around AES for this
> reason and in order to take advantage of hardware support. If you have
> one in mind then it should be considered, but I believe that
> AES-GCM-SIV is very useful as a tweak of AES-GCM and I'm not sure what
> an alternative would usefully provide without venturing into being
> "more exciting". I would like CAESAR to produce a primitive that
> provides cool features like AEZ's (any maybe other's) arbitrary block
> size. But, for now, I would welcome a slightly more robust AES-GCM.
>
>
> Cheers
>
> AGL
>