Re: [Cfrg] AES-GCM-SIV security of the additional data

"Gueron, Shay" <> Sat, 25 June 2016 09:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6032612D107 for <>; Sat, 25 Jun 2016 02:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KPh34wIl0Ffd for <>; Sat, 25 Jun 2016 02:58:48 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2C6512D0E5 for <>; Sat, 25 Jun 2016 02:58:47 -0700 (PDT)
Received: by with SMTP id c82so11438113wme.3 for <>; Sat, 25 Jun 2016 02:58:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version:content-transfer-encoding; bh=6+C+3WWyrgdiG7jBpWCmpBTnfJ79QN9ae1J+8wy+iX4=; b=iscw1po6grN2BZXCW9Xz/spu2Nt+CucnoqWCw2wQ7lD/CcsGhHvfHqe/NzDTm04/ms NQzr0cR4i18Vnp71lbghTs7HZi1yfN4Dn45+1uyjDAYCZ1SZBwRb3W3sb1ksdQvlSU/F YU9s66i09de/QefnwLwQQwVSZBTi7NdzCemi0KdzESw1AGzcJ/TpYkIuh9gGXOufBV28 0nsTW5bdBYWOFuSbp2rxLh9oKBpr1SGhrSH7V20gxml2Iwo+kWMxqwxsT+5JYDxtSpTn SjW8QRUgYPcFC7bR0HITAW4jVjD50bWTH/6pX0+Z/OAfTiCbKzS5VIn6DHLAYbWfwNDJ wjwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version:content-transfer-encoding; bh=6+C+3WWyrgdiG7jBpWCmpBTnfJ79QN9ae1J+8wy+iX4=; b=dHEwHWCm3z66Xo85xzcTJ0G/sG87ImOWLfBiYhBQg4bWAkWsXRz/s+2I0pe9Ad6mBN WkcEpHnlcg43TAslHwgDDeYLq7xs7IQhWkeDcxfZgLgplFLQs8IjnWzFMeGV8sLca3FJ O4fxqfxFCfAEHmBumEd4KPVevXqWRIIKeyFvRQWgIXbb3ni2I7zsRznLh0hmDBtrYDu7 aTq56BQqCoNHa+XTkBN4YpZWQWSGJe6RcSGmPWq/7impB45fFnC61UQtcgFp48tA2yiw PKqZ7TW8mZ8iFhgqCCwp5px0WwQ+Vcu/FGM8LaBxmOiLybCtEPEULdO0k5ZWEDTHGGGy 1ttQ==
X-Gm-Message-State: ALyK8tKa5UpPARwQzdBTrTBxCW44vqyT5hetpq2BCX8he3D4K4Bue+xRcRoAULmajKIJZg==
X-Received: by with SMTP id a6mr7568590wjq.106.1466848726076; Sat, 25 Jun 2016 02:58:46 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id el4sm1619348wjd.23.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 25 Jun 2016 02:58:45 -0700 (PDT)
From: "Gueron, Shay" <>
To: "Paterson, Kenny" <>, Adam Langley <>
Date: Sat, 25 Jun 2016 09:58:34 +0000
Message-Id: <emd7a7bf2e-7d2d-47b0-9ff3-9a88b73cb7c3@sgueron-mobl3>
In-Reply-To: <>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Resent-To: <>
Cc: "" <>
Subject: Re: [Cfrg] AES-GCM-SIV security of the additional data
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "Gueron, Shay" <>
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 25 Jun 2016 09:58:50 -0000

I would like to clarify a point.

The API is a technical matter, so K1||K2 are K1, K2 are the same - from 
the logical viewpoint. The interface can use a single 32/48 bytes key, 
and this is how the draft is stated. This separation seemed to us as a 
*advantage* of the design, and this is what I tried to communicate in 
Vienna. I guess the confusion is due to my explanation... and hope it is 
clarified here.

With both interfaces, the property is that the authentication key is 
independent of the encryption key, and both are a direct input (unlike 
AES-GCM that derives the authentication key from a single input key).

Daniel's example showed that here exists a (flawed/artificial) protocol 
that would not work when using AES-GCM-SIV, but would be OK with 
It is not a problem of AES-GCM-SIV, which is designed as an AEAD scheme 
for the standard usage, and also, the protocol does not make much sense 
(to me, at least). Still, it is a very interesting observation.

The difference stems exactly from using 2 independent keys with 
AES-GCM-SIV, while using a single key with AES-GCM, and deriving H from 
it (by a one way function). It is the same for other AEAD schemes that 
use independent encryption and hash keys, where there are some "weak" 
hash keys (e.g., 0). This property affects any protocol that benefits a 
malicious sender (who could choose a bad hash key).

Should this needs to be addressed? I am not sure. A malicious sender is 
not part of the AEAD threat model.

But in any case, it could be addressed if AES-GCM-SIV used a single key 
(MK) and derived K1 and K2 from MK (and possibly the nonce). I raised 
this point in another thread.

Thanks, Shay

------ Original Message ------
From: "Paterson, Kenny" <>
To: "Adam Langley" <>
Cc: "" <>
Sent: 6/25/2016 11:40:51 AM
Subject: Re: [Cfrg] AES-GCM-SIV security of the additional data

>Hi Adam,
>Thanks for the clarification. My remarks were based on the scheme as 
>presented by Shay at Vienna; there, he introduced the misconception 
>that two separate keys were involved; he did not clarify this during 
>questioning (see the minutes).
>Of course the draft is definitive document and it's good that it 
>presents the normal API.
>Sent from my iPhone
>>  On 25 Jun 2016, at 02:43, Adam Langley <> 
>>  On Fri, Jun 24, 2016 at 6:24 AM, Paterson, Kenny
>>  <> wrote:
>>>  On a related point, my view is that it is a disbenefit that the
>>>  AES-GCM-SIV proposal has two separate keys (one for encryption, the 
>>>  for authentication) as inputs. That's not the AEAD interface that we 
>>>  raised our implementers on. I raised this point at the CFRG meeting 
>>>  Vienna back in May. Simply concatenating the two keys in the current
>>>  proposal into one would address this issue, but not the one you 
>>>raise (if
>>>  I understand it correctly).
>>  The two keys are already concatenated in the draft, or else I
>>  misunderstood your point:
>>  "Since the definition of an AEAD requires that the key be a single
>>  value we define AEAD_AES_128_GCM_SIV to take a 32-byte key: the first
>>  16 bytes of which are used as the authentication key and the 
>>  16 bytes are used as the AES key. Likewise AEAD_AES_256_GCM_SIV takes
>>  an 48-byte key: the first 16 bytes are again the authentication key
>>  and the remaining 32 bytes is the AES key."
>>  Cheers
>>  AGL
>>  --
>>  Adam Langley
>Cfrg mailing list