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

[Shay Gueron <[e-mail]>]

OK, let me explain:

There are (only) two options for the key: 128 bit or 256 bits.

For the "128-bit" case, the document states
"If the AES key is 16 bytes long then define the _record-encryption-key_ as
the encryption of the nonce using the AES key".
That is AES128 (NONCE)  (using the 128-bit key). This is the
straightforward case.

The "256-bit" case, is covered in my previous explanation, basically:

AES256 (NONCE[127:1] || 0) || AES256 (NONCE[127:1] || 1)  (using the
256-bit key, and producing 256 bits altogether).

I hope this helps. We will definitely edit the text and post a version that
includes these explanations (soon).

Thank you, Shay



2016-04-08 7:11 GMT+03:00 Andy Lutomirski <[e-mail]>:

> On Thu, Apr 7, 2016 at 9:00 PM, Gueron, Shay <[e-mail]>
> wrote:
> >  Regarding:
> >
> > ****
> > The only relevant text I can find in the draft is:
> >
> > If the AES key is 16 bytes long then define the _record-encryption
> > key_ as the encryption of the nonce using the AES key. If AES-256 is
> > being used then this is insufficient as 256 bits of key material are
> > needed. Therefore the record-encryption key in this case is 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.
> >
> > This very much sounds to be like (a) a 256-bit key is derived from a
> > 128-bit key and (b) the draft doesn't actually specify what the record
> > key is in any other case. I interpreted the vague text to mean that
> > the record key is the AES key in all other cases.
> >
> > Can you clarify the draft?
> >
> > --Andy
> > ****
> >
> > Yes, of course. Here is the paragraph with explanatory notes in *** ...
> ***
> >
> > If the AES key is 16 bytes long then define the _record-encryption
> > key_ as the encryption of the nonce using the AES key. *** so far, the
> case
> > of 128-bit key***
> >
> > If AES-256 is being used *** now the case of 256-bit key***
> > then this is insufficient as 256 bits of key material are needed ***
> because
> > one invocation produces only 128 bits, and we want to derive a 256-bit
> key
> > ***
> > Therefore the record-encryption key in this case is the *** here is the
> > explanation: ***
> > concatenation of the result of encrypting, using the AES key *** recall
> that
> > it is the 256-bit case***, the nonce with the least-significant bit of
> the
> > first byte set to zero and then to one.
> > *** that is AES  New key (256 bits) =  AES256 (NONCE[127:1] || 0) ||
> AES256
> > (NONCE[127:1] || 1)  (256 bits altogether).
> >
> > Thus, "This very much sounds to be like (a) a 256-bit key is derived
> from a
> > 128-bit key and (b) the draft doesn't actually specify what the record"
> is
> > not the case.
> > Shay
> >
>
> Hmm, I guess I didn't read it quite right.
>
> What happens if AES-128 is used and the "AES key" is 32 bytes long?
> Or is this not allowed?
>
> It might help to clarify exactly what variants of this scheme exist in
> terms of AES variant and key size.
>
> --Andy
>