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

Antonio Sanso <> Fri, 24 June 2016 13:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BC1A12DAE9 for <>; Fri, 24 Jun 2016 06:41:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_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 gta6sVTB4yc1 for <>; Fri, 24 Jun 2016 06:41:31 -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 D52A212DAEF for <>; Fri, 24 Jun 2016 06:40:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jmIIkDaTjBUiG3ptpjbFfx9F3mAhFaskUktakO+mpNw=; b=pxHP3ZrpGRt4kY5jlOT1/wI0FrthRoaUhIj6x6vO5FXWrc39Zz7jBImsbfablVW+MMP5PMmWLk98MBvr+9tzC0CWEeN3TeXvzIMsUZBiIzIbUe0XzEGl2M2GZDbvEJzOWkI6H0dGK3kkA0hO3it9YjZ31D2exu3AnpTiOTQfIDY=
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.523.12; Fri, 24 Jun 2016 13:40:31 +0000
Received: from ([]) by ([]) with mapi id 15.01.0523.019; Fri, 24 Jun 2016 13:40:31 +0000
From: Antonio Sanso <>
To: "Paterson, Kenny" <>
Thread-Topic: [Cfrg] AES-GCM-SIV security of the additional data
Thread-Index: AQHRzgyHGT1YRe0Ankm4eF10cRh2kZ/4m2wAgAAEbwA=
Date: Fri, 24 Jun 2016 13:40:31 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 250a9dac-c2ed-4f61-c2c6-08d39c351ca3
x-microsoft-exchange-diagnostics: 1; BY1PR0201MB1031; 6:is3KHHWu2Y/2LAsg5p/qj8Rr9IFVVpL54EEmO8UgEaoeEp8bz0lMTf05ikk4YTmvCr3crrIPrkBKxp0NRhE3nTpZvHTH1TfqwCdx1oLjyt+3bz1ZOTuNFfskMVjmddtjemudAwKXsVP/gly3vxgVjgPHXRXyV1YZnGfVlMr37di4rEOaKFLcLlyrtmXi0JSctJ7ORXRJhs7hhj4PlvV5DQ0xyRrcpjpVTiySPAWYaeRCPG3LscggaPQH797WyfCbkH1ZoyNrY69NwuI5kYXQUiE6MgB225hyUS0LcTRtqD6wZ1n3D1nC3uGXbhSYDCes2K+9839+BQSUoFGOc78lx3Uy/j60mhw4Xu+aPm5afbw=; 5:r9EcsYHrVk22mTQVcAP0ohUvKGqLmUAONGcdhaV60R9JCjMMF/F+yaV7pUvfBNn6z8uAiJApoltJbHnstMeKxJxlLwYudbAxMEzTNXNsVY6NrV/7pPVN2HTECVZ4nA5inXEzMazd4eDEYzSctJlkTw==; 24:Fk7S+KeZVV6L1mCwe00OBOLpDS1D8zLCb5Zk6QhvJ3feuNW9xYkP+GyBrs7q/FTGtxoYqnwIEtON2DHaiagOnV1e2d+l+liyQibaLPhzNF4=; 7:fMU9xRjMKLEdpfSzRRHpkV/hSQFm1hzSNkRC2REdY49aKzfMT2pqnnHPLTWrBOLnowmz0ZeR/VgzsrMplYwHY81x7LburA5/YXD/9GMEZ+KPEhcGMDgWWUTk52f2Gn6NdTHiOp0MmNtDReAm4PtcDeS9VMw0GHKpv8NGWD/VvbMyH+3awBjx58NqDfxab5MYULdu+jZN2CboDk8XNS+/5RPUvjGtkJE2p4GW6+AtiyM8R5tftTzzCEVHcND8Zeb33WCmGXyBo4XlsTBipcS5iw==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0201MB1031;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(192374486261705)(211936372134217);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR0201MB1031; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0201MB1031;
x-forefront-prvs: 0983EAD6B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(7916002)(377454003)(199003)(189002)(24454002)(7736002)(6116002)(102836003)(8676002)(54356999)(83716003)(11100500001)(3846002)(92566002)(2906002)(36756003)(305945005)(82746002)(50986999)(86362001)(105586002)(76176999)(101416001)(586003)(230783001)(10400500002)(189998001)(81166006)(122556002)(81156014)(106116001)(33656002)(106356001)(15650500001)(3660700001)(561944003)(99286002)(97736004)(68736007)(8936002)(3280700002)(66066001)(2900100001)(10090500001)(7846002)(2950100001)(87936001)(5002640100001)(77096005)(110136002)(19580395003)(8666005)(19580405001)(15975445007)(4326007)(7059030)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR0201MB1031;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2016 13:40:31.5154 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0201MB1031
Archived-At: <>
Resent-To: <>
Cc: "" <>
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:41:33 -0000

hi Kenny

On Jun 24, 2016, at 3:24 PM, Paterson, Kenny <> wrote:

> 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

to me this seems a pretty common scenario.
If I am not completely wrong in my understanding is for example what JWE does [0] and [1] for example




> . 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:
> 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 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.
> _______________________________________________
> Cfrg mailing list