Re: [Cfrg] AES-GCM-SIV with a new key hierarchy

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

Since the traditional assumption for AEAD interface is “you use one key
that is responsible for both confidentiality and integrity”, I’m in favor
of defining such an interface for AES-GCM-SIV.

In that case IMHO it makes sense to incorporate nonce from the beginning,
using the same AES-OFB approach.

Thanks!
-- 
Regards,
Uri Blumenthal





On 6/24/16, 13:10 , "Cfrg on behalf of Gueron, Shay"
<[e-mail] on behalf of [e-mail]> wrote:

>Hello everyone,
>
>I start a new tread.
>
>It is a branch off the one entitled "AES-GCM-SIV security of the
>additional data" and initiated by Daniel.
>
>It combine Kenny's inputs about having two separate keys and the AEADE
>interface (which he raised at the CFRG meeting in
>Vienna in May and also mentioned, in the previous thread, that
>concatenating 2 separate keys does not solve the problem that Daniel
>raised).
>
>It also address a comment that Bart Preneel made at that CFRG meeting.
>
>****
>
>It is possible to define AES-GCM-SIV with a standard interface that has
>a single key (say, MK for "Master Key"), which can be 128 or 256 bits.
>Basically, by adding the following key derivation step:
>
>     Using MK, derive two new keys K and H: K for encryption and H for
>authentication.
>     From that point on, apply AES-GCM-SIV as it is defined now, where
>(K, H) are the keys.
>
>Note that K and H are derived statically from MK. The "record encryption
>key" for the encryption depends on the nonce N, via another derivation,
>as it is currently defined in AES-GCM-SIV.
>
>Note: the derivations are different for the 128 and the 256 bit keys,
>but such derivations are already in use by AES-GCM-SIV.
>With this, AES-GM-SIV could be used with the protocol Daniel described,
>and would address Kenny's comment on the AEAD interface.
>(I guess that it could be better viewed as a drop in replacement to
>AES-GCM)
>
>The cost is the additional key derivation. this cost could be low if the
>message is long, or if many messages are encrypted (so that K, H can be
>cached).
>
>An alternative would be to incorporate the nonce from the beginning,
>during the derivation of K, H from MK. This will modify the record
>encryption key and also the hash key per each nonce. In that case the
>extra derivation of the record encryption key (per nonce) could be
>skipped (but also could be not done).
>
>I would appreciate any comments on this.
>
>Thanks, Shay
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/cfrg
>