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

[Shay Gueron <[e-mail]>]

Andy,

Addressing your concern:
>>> This has the odd property that the
>>> record encryption key is the same for two messages with nonces that
>>> differ only in the LSB of the first byte.
This is not the case. What the spec states means the following:
The record encryption key is derived by

AES256 (NONCE[127:1] || 0) || AES256 (NONCE[127:1] || 1)

I hope this helps clarifying.
Regards, Shay




2016-04-21 22:45 GMT+03:00 Andy Lutomirski <[e-mail]>:

> On Thu, Apr 14, 2016 at 2:12 PM, Adam Langley <[e-mail]>
> wrote:
> > On Thu, Apr 7, 2016 at 4:55 PM, Adam Langley <[e-mail]>
> wrote:
> >> Will do as soon as I'm able (which should be next week).
> >
> > -03 is hopefully clearer on this point:
> > https://tools.ietf.org/html/draft-gueron-gcmsiv-03#section-4
>
> This is much clearer to me.
>
> However:
>
>    This record-encryption
>    key is defined as the concatenation of the result of encrypting,
>    using the AES key, the nonce with the least-significant bit of the
>    first byte set to zero and then to one.
>
> Why is it designed this way?  This has the odd property that the
> record encryption key is the same for two messages with nonces that
> differ only in the LSB of the first byte.
>
> Alternative designs include:
>
> a) Concatenate the results of encrypting the nonce and the none with
> the LSB of the first byte flipped.
>
> b) Concatenate the results of encrypting the nonce and the nonce + 1.
>
> Both of these will have related nonces generate related keys, but at
> least they won't generate the *same* key.
>
> It still seems to be that performance for short block sizes may be
> rather poor given the key setup needed.
>
> --Andy
>