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

["Gueron, Shay" <[e-mail]>]

  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


------ Original Message ------
From: "Andy Lutomirski" <[e-mail]>
To: "Gueron, Shay" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>; "Adam Langley" 
<[e-mail]>; "Yehuda Lindell" <[e-mail]>; 
"Adam Langley" <[e-mail]>
Sent: 4/8/2016 2:16:07 AM
Subject: Re: [Cfrg] Adopting "AES-GCM-SIV: Nonce Misuse-Resistant 
Authenticated Encryption" as a CFRG document ---- Some clarifications

>On Tue, Apr 5, 2016 at 6:14 AM, Gueron, Shay <[e-mail]> 
>wrote:
>>  The (ACM CCS) paper described a GCM-SIV implementation with 128-bit 
>>keys.
>>  The CFRG submission is different in two respects:
>>  1. A 256-bit version that is added.
>>  2. There is key derivation added (based on the nonce) to refresh the
>>  encryption key for each record.
>>
>>  The purpose of #2 is to allow AES-GCM-SIV to use a single key 
>>multiple
>>  times. In the original paper version, an IV is derived from the 
>>universal
>>  hash function (and the nonce) over the message, and occupies 95 bits 
>>of the
>>  counter block during the encryption. Collisions are imminent after 
>>2^48
>>  uses, and to maintain safety margins, we would need to restrict the 
>>usage of
>>  one key to 2^32 messages. This could seem like a real constraint for 
>>a real
>>  AE scheme. With a differently derived key (derived from the nonce), 
>>the
>>  lifetime of one key can be extended.
>>
>>  The cost of extending the lifetime of the key is that of computing a 
>>key
>>  schedule, but this overhead is small on the target platforms that 
>>have AES
>>  hardware support.
>>
>>  To clarify a possible confusion about the 256-bit variant: no 256-bit 
>>key is
>>  ever derived from a 128-bit key. A 256-bit encryption key is derived 
>>from
>>  the 256-bit master key and a (128-bit) nonce but two encryptions. The
>>  authentication key has 128 bits, and so does the authentication tag.
>
>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