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

[Andy Lutomirski <[e-mail]>]

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