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

["Paterson, Kenny" <[e-mail]>]

Hi Shay

Thanks for presenting these options.

Could you summarise what the impact would be on your security proofs of
each of the three options, if any?

I'd also be interested to see an explicit accounting for the performance
impacts - this could be roughly characterised in terms of the number of
AES operations involved in key derivation per message in each case.

Cheers

Kenny 

On 26/06/2016 09:26, "Cfrg on behalf of Gueron, Shay"
<[e-mail] on behalf of [e-mail]> wrote:

>Of course - let me describe.
>For simplicity, I describe the case of a 128-bit MK.
>
>Option 1: K1 = E_MK (0), K2 = E_K1 (0)  (K1 will be used for encryption,
>and K2 for the authentication)
>Then continue AES-GCM-SIV as it is defined now (including a derivation
>of a record encryption key, per nonce N)
>
>Option 2: K1 = E_MK (N), K2 = E_K1 (N)
>Then AES-GCM-SIV as it is defined now, but without an  additional
>derivation of a record encryption key; just set K1 as the record
>encryption key.
>
>Note: Option 1 is merely a static "pre-derivation" (where K1, K2 can be
>cached). Here, MK is used directly only twice.
>Option 2 uses MK (directly) with each nonce. Here, the hash key also
>depend on the nonce.
>
>There is another option.
>
>Option 3: K1 = E_MK (0), K2 = E_K1 (0)
>Then continue AES-GCM-SIV as it is defined now (including a derivation
>of a record encryption key, per nonce N) and also define a record hash
>key via E_K2 (N).
>
>
>These options offer different nuances, and would have a noticeable
>performance effect only for short messages. My favorite, among these 3,
>is Option 3 (that seems to enjoy all the benefits, at a small additional
>latency).
>
>
>Shay
>
>
>------ Original Message ------
>From: "Aaron Zauner" <[e-mail]>
>To: "Gueron, Shay" <[e-mail]>
>Cc: "[e-mail]" <[e-mail]>; "Yehuda Lindell"
><[e-mail]>; "Adam Langley" <[e-mail]>
>Sent: 6/26/2016 11:07:36 AM
>Subject: Re: [Cfrg] AES-GCM-SIV with a new key hierarchy
>
>>Hi,
>>>  On 25 Jun 2016, at 01:10, Gueron, Shay <[e-mail]> wrote:
>>>
>>>  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).
>>
>>Could you clarify on that paragraph? e.g. with pseudocode?
>>
>>Incorporating the nonce in the MK derivation step makes sense to me.
>>
>>But; I don't fully grasp the last part of this paragraph; if you skip
>>the extra derivation per record encryption key per nonce you lose
>>nonce-MR?! Given the nonce is incorporated in the MK derivation step,
>>this isn't an issue, but I'm not 100% sure what your suggestion here
>>is.
>>
>>Thanks,
>>Aaron
>
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/cfrg