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

"Paterson, Kenny" <> Fri, 24 June 2016 13:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C956412D110 for <>; Fri, 24 Jun 2016 06:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m52TUGCe8tEp for <>; Fri, 24 Jun 2016 06:24:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF85312D0E9 for <>; Fri, 24 Jun 2016 06:24:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-rhul-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CHhQye9XVq3CPUa5Pp0KE0Chh5Yi5IyYXiEhnADqvD8=; b=HilOS7Tga+/jsCuyJBQce5YK/x3PCkPldthC7f6Q/OeKnijSBqLQ/JynJwyib1Fi9dxcd3Y58jzzoJ2t0mHTIAu7uyXJQO8Lxo9k/i+tNoekVaqQ5ezZEQnScK0fM0FanTHHzodDyAkRrIqZCBSzWlp7jEhaaKI1PC0AGckyE/o=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.523.12; Fri, 24 Jun 2016 13:24:40 +0000
Received: from ([]) by ([]) with mapi id 15.01.0523.019; Fri, 24 Jun 2016 13:24:40 +0000
From: "Paterson, Kenny" <>
To: Daniel Bleichenbacher <>, "" <>
Thread-Topic: [Cfrg] AES-GCM-SIV security of the additional data
Thread-Index: AQHRzgyMNFkKTSqpJkGxUgqboNSngJ/4rLoA
Date: Fri, 24 Jun 2016 13:24:40 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: daa41899-0994-447d-4814-08d39c32e5b9
x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 6:AfsU9l1EZ0ZRxRtOZk0sBKD0YPN50B8bU1Yzp47WQx3e/ABsels7lQ5iKCC0YkOXDJbMEXn10QEkl6jqlySycTwW9ODJnEVZ4L+btQN1UTwCdF4H9I41XPvchur8bhKVOfHQafC4aMcT2Joi0XbJ2Qzan8vlHgP/JgsbE1SR7ltjVKNJZOIGNdLM/8nPYKCQdJ1FfNPIC+DFNsl2QV4QK/pwYwBtVClWAfgre/tsptHgvb54gCSyXT2ws6EvZ8LlwhzTVQz62E4gwtKi/nzFLhqcdAWoN0W/CRAaF3Vq33V7v6/U5smSeOr2bOQEB9qq; 5:fHq9C5IpN75Gs5fRnxGS2hZUsXnqB479F0ikDCcZ4gGN4tQQ5sED7hMBmSdLgrByqan9zIGlYowPWSqrNbZ7qCUSwV1kBVikntUXzh3qxK4EKulXCc9yaZT4FqOrhiUgI4z1qqe+mwTrPC2b3vzHwg==; 24:VOHP9EDZLMAhH8Z+9ssTXTQNGLIFQu66VQ+JjNmbBYf5nPi3J6ncU6X644ZPk8fJysWGYoNittdeEvJKA75ZRLfI3jcTvSbu8VNwtkLXQHU=; 7:ul5UiRrOYUtzEHXGNRAYNLS4HCpvPaJ4EPusuvntNLJh687WwgOXMRTOZQE35Tnk/SvGDDEVNtkUJ9myCzXTpkzzfgkEEojl95z4Cu+ZNE0N/LlOZrRN8QLeyZfHt0THg9Tl01NotSW/qRy6wjiL1QCfEenig3QPoUi+WXHIGtLShL5vM2gCh4tWIQEBQD92aCBM0CsyPbsNELsiBE8tvyb3RZL++7y8HzTSEyTy5JII1y9BZF3sH39G3Hj/311SKtRFZSIDQS6o3QdYAidNYw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(192374486261705)(211936372134217);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822;
x-forefront-prvs: 0983EAD6B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(199003)(97736004)(83506001)(86362001)(5001770100001)(189998001)(66066001)(76176999)(4001350100001)(8676002)(11100500001)(3280700002)(106356001)(10400500002)(107886002)(305945005)(7736002)(19580405001)(19580395003)(87936001)(105586002)(92566002)(2906002)(81156014)(106116001)(54356999)(50986999)(5002640100001)(81166006)(68736007)(77096005)(101416001)(15975445007)(2900100001)(3660700001)(122556002)(2950100001)(36756003)(102836003)(586003)(2501003)(68196006)(230783001)(561944003)(3846002)(15650500001)(74482002)(6116002)(7846002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2016 13:24:40.4944 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822
Archived-At: <>
Resent-To: <>
Subject: Re: [Cfrg] AES-GCM-SIV security of the additional data
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 13:24:48 -0000

Hi Daniel,

Thanks for your message.

The usual expectation in AEAD is that the AD is integrity protected, but
there's no assurance as to its confidentiality. It's not usually
considered part of the ciphertext, but might be included along with it in
a message being sent to a receiver, or might be reconstructed from other
data/context by the receiver.

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. In this scenario, it's
not clear to me why the sender and receiver would not just use S as an
AES-GCM-SIV key to transport a session key K, and then use K in another
instance of AES-GCM-SIV to transport the desired messages. Of course, this
construction would not prevent replay attacks; for that you'd need
additional mechanisms, like incorporating a counter into the AD of the
key-transporting AEAD.

But perhaps one should not underestimate the ingenuity of implementers in
wanting to use public key encryption. Is this where you are coming from?

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 other
for authentication) as inputs. That's not the AEAD interface that we have
raised our implementers on. I raised this point at the CFRG meeting in
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 minutes of the meeting can be found here:



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 the
>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 with
>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 such
>that the
>element H used for POLYVAL is 0. In this case it would not be necessary
>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 for
>the GHASH
>is obtained by encrypting 0 and thus I'm not aware of a way to do the
>same thing here.
>The attack does of course not violate any of the guarantees claimed.
>However, in the industry lots of ad hoc protocols are designed without
>proper security reductions and hence it seems a bit scary to me to allow
>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 abuses.