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

"Blumenthal, Uri - 0553 - MITLL" <> Fri, 24 June 2016 18:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF7BA12DD3E for <>; Fri, 24 Jun 2016 11:07:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.624
X-Spam-Status: No, score=-5.624 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tfWaCu-ADEdd for <>; Fri, 24 Jun 2016 11:07:20 -0700 (PDT)
Received: from (LLMX2.LL.MIT.EDU []) by (Postfix) with ESMTP id A243B12DD24 for <>; Fri, 24 Jun 2016 11:07:20 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id u5OI4jT0045042; Fri, 24 Jun 2016 14:04:45 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: "Gueron, Shay" <>, "" <>
Thread-Topic: [Cfrg] AES-GCM-SIV with a new key hierarchy
Thread-Index: AQHRzjuXQ8G4tUR43UGKZ6u6dVybJp/46fwA
Date: Fri, 24 Jun 2016 18:07:14 +0000
Message-ID: <>
References: <ema3c568ce-b47f-45fc-b799-b78ad0494efd@sgueron-mobl3> <em85e6ab2a-6a3c-4b2e-986d-2e44c2965663@sgueron-mobl3>
In-Reply-To: <em85e6ab2a-6a3c-4b2e-986d-2e44c2965663@sgueron-mobl3>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha384"; boundary="B_3549622030_5077918"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-24_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606240193
Archived-At: <>
Resent-To: <>
Cc: Yehuda Lindell <>, Adam Langley <>
Subject: Re: [Cfrg] AES-GCM-SIV with a new key hierarchy
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 24 Jun 2016 18:07:23 -0000

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.

Uri Blumenthal

On 6/24/16, 13:10 , "Cfrg on behalf of Gueron, Shay"
< on behalf of> 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
>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
>     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
>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
>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