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

"Gueron, Shay" <> Fri, 24 June 2016 14:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2A5DE12D7F8 for <>; Fri, 24 Jun 2016 07:23:55 -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 VW13pJO-9hLK for <>; Fri, 24 Jun 2016 07:23:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 824EA128874 for <>; Fri, 24 Jun 2016 07:23:52 -0700 (PDT)
Received: by with SMTP id r201so5425841wme.0 for <>; Fri, 24 Jun 2016 07:23:52 -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=kcJh4SMIXYQ26KifDeSYvieeOWA6O3SMhg04kZvY8Tg=; b=bzZ4eTdpxPSnWOtfpX3B9rSijAVCCvZHBaN8+HDDfn1ltBNe1bapVYie/CvQhiOxgU qb3bkAF2H1Jc89Eke1cWVtq95u+9HJkN7ZeUHNtFmMTRsBsmU79gY2D8KeA/8Ufh3RiS llEzGoIOZ5c2ic6Yr7K7Kb8qZt27idzFc9hy4M5K1VvIN3JtenBqDiD6M1D4u4x/Zdfv HPHmt9iMT9Q307gQzrgtn8UOgmktoBuTBDOt9TIpJflSqui/XyVtiFRiKtVxK7xSVjFg i8DRxO1YXNOUfp8iXQ6C0wE5k0mpC0/2adBPMmXC8DJuZhi91HxiIWNKZTqWGOVrnWSv XoaA==
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=kcJh4SMIXYQ26KifDeSYvieeOWA6O3SMhg04kZvY8Tg=; b=PsT0kZLiSFOwkkyUVHPG4biVJBf3nTse7+lbN4mHPcvZtl6TZ1i/k2Nk9tclP9pmBg NStb7FIdf2tp7P4W7DB5gYqNnq1+Ia3rhEHjxNlWeMsTu4uaHpr4BsSRhmSv6Ze1NzeQ qlZ1x/zTFJdivc/C/w0RaG7B5qCZqkYAnCvjZXLbGRjF9u4NOpfTbuu5GZW/eP67hPrt CW9O2h0lqwyLW7Hv/Yei1yxE2XJkWSruSGdjNhrIU6Rq8ADroxgqVsvThtFmtvVlwonH 1h27r1STPu8NGRhh65+7NktrSOgVvIzrNAADkDBbz0lXh6hF8gOcsuQ2nx18z0hXd/zy hBuw==
X-Gm-Message-State: ALyK8tKYy9cRpewzAW6P4/CfA1aVXd0SxtemuseoOQZrPU0lF1x1+I/VtKmUNyePNNJ3Cw==
X-Received: by with SMTP id jq7mr4023458wjb.162.1466778230962; Fri, 24 Jun 2016 07:23:50 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id a129sm3409058wma.2.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 24 Jun 2016 07:23:50 -0700 (PDT)
From: "Gueron, Shay" <>
To: "Paterson, Kenny" <>, Antonio Sanso <>
Date: Fri, 24 Jun 2016 14:23:36 +0000
Message-Id: <ema3c568ce-b47f-45fc-b799-b78ad0494efd@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: Yehuda Lindell <>, "" <>, Adam Langley <>
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: Fri, 24 Jun 2016 14:23:55 -0000

Hello to Daniel (and all) –

This is a very interesting point, raised by Daniel.
It does not attack AES-GCM-SIV, but rather a particular (imaginary) way 
to (not) use it.
Daniel's demonstration shows that there exists a protocol that is safe 
(I guess) when using AES-GCM as a component, but not safe when 
(carelessly) using AES-GCM-SIV as this component. Indeed, so.

But, as Daniel indicated, it does not violate the promise of 
AES-GCM-SIV, and the simple answer is: don’t use protocols (certainly 
not made-up) without proper analysis.

To Kenny: it does not matter here if the there is a single key where a 
part of it are used for encryption, and another part for the 
authentication, or 2 separate keys. Because, the adversary controls this 
key (or the two keys) in the described scenario.

About the protocol: if there is already a shared secret (S), why not use 
it directly with AES-GCM-SIV (where different nonces, that yield 
different encryption keys), as Kenny has already indicated.

If someone insists on using such a hybrid protocol (why?), then how 
about this change in it: draw K1 and x uniformly at random, and define 
K1 as the encryption key, and K2 = ENC_S (x) as the authentication key. 
Then use AES-GCM-SIV with these keys and the mentioned protocol. This 
addresses the root cause for the protocol’s failure: now, the adversary 
does not control the authentication key and cannot force a “weak” (zero) 
one to be used.
[disclaimer: I have not analyzed the protocol in depth]
Thanks, Shay
------ Original Message ------
From: "Paterson, Kenny" <>
To: "Antonio Sanso" <>
Cc: "" <>
Sent: 6/24/2016 4:53:46 PM
Subject: Re: [Cfrg] AES-GCM-SIV security of the additional data

>Hi Antonio,
>On 24/06/2016 14:40, "Antonio Sanso" <> wrote:
>>hi Kenny
>>On Jun 24, 2016, at 3:24 PM, Paterson, Kenny 
>>>  In your scenario it looks like you are trying to use the shared 
>>>secret S
>>>  to provide authentication of the sender to the receiver, along with
>>>  confidentiality for the message being delivered
>>to me this seems a pretty common scenario.
>>If I am not completely wrong in my understanding is for example what 
>>does [0] and [1] for example
>Key transport via PKE using, for example RSA-OAEP, is a certainly an
>option in JWE. But what Daniel describes has an additional symmetric 
>("S") for the purposes of authentication, I think, and does not 
>match anything I've seen in the JSON RFCs. But let's allow Daniel to
>answer on that one...
>>>  . In this scenario, it's
>>>  not clear to me why the sender and receiver would not just use S as 
>>>  AES-GCM-SIV key to transport a session key K, and then use K in 
>>>  instance of AES-GCM-SIV to transport the desired messages. Of 
>>>  construction would not prevent replay attacks; for that you'd need
>>>  additional mechanisms, like incorporating a counter into the AD of 
>>>  key-transporting AEAD.
>>>  But perhaps one should not underestimate the ingenuity of 
>>>  wanting to use public key encryption. Is this where you are coming 
>>>  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 
>>>  I understand it correctly).
>>>  (The minutes of the meeting can be found here:
>>>  im-2016-cfrg-1)
>>>  Regards
>>>  Kenny
>>>  On 24/06/2016 12:35, "Cfrg on behalf of Daniel Bleichenbacher"
>>>  < on behalf of> wrote:
>>>>  I'm wondering what can or should be expected about the security of 
>>>>  additional data.
>>>>  In particular, I'm considering the following scenario:
>>>>  Sender and receiver share a secret S.
>>>>  The sender knows the public key of the receiver and the receiver of
>>>>  course knows the private key.
>>>>  They use a hybrid encryption as follows:
>>>>  The sender chooses a new AES-GCM-SIV key, encrypts his message
>>>>  and includes S as additional data. The AES-GCM-SIV key is wrapped 
>>>>  the receivers public key and the wrapped key and ciphertext are 
>>>>sent to
>>>>  the receiver.
>>>>  Here an attacker can use that AES-GCM-SIV allows to select a key 
>>>>  that the
>>>>  element H used for POLYVAL is 0. In this case it would not be 
>>>>  for the sender
>>>>  to know S to construct a ciphertext that validates.
>>>>  A similar attack using AES-GCM seems much harder since the value H 
>>>>  the GHASH
>>>>  is obtained by encrypting 0 and thus I'm not aware of a way to do 
>>>>  same thing here.
>>>>  The attack does of course not violate any of the guarantees 
>>>>  However, in the industry lots of ad hoc protocols are designed 
>>>>  proper security reductions and hence it seems a bit scary to me to
>>>>  this kind of "weak" keys. And since abuse resistance is
>>>>  one of the goals it might be a good idea to avoid such type of 
>>>  _______________________________________________
>>>  Cfrg mailing list
>Cfrg mailing list