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

"Blumenthal, Uri - 0553 - MITLL" <> Fri, 24 June 2016 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E418412DA8F for <>; Fri, 24 Jun 2016 06:08:20 -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, HTML_MESSAGE=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 6i2ucyEkpRbb for <>; Fri, 24 Jun 2016 06:08:18 -0700 (PDT)
Received: from (LLMX2.LL.MIT.EDU []) by (Postfix) with ESMTP id 9AD7C12DA77 for <>; Fri, 24 Jun 2016 06:08:13 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id u5OD5fSa003772; Fri, 24 Jun 2016 09:05:41 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: Daniel Bleichenbacher <>, "" <>
Thread-Topic: [Cfrg] AES-GCM-SIV security of the additional data
Thread-Index: AdHOGXPgqD25y0zmskKltSj3U+rSKQ==
Date: Fri, 24 Jun 2016 13:08:09 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="===============0304649693=="
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-24_06:, , 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-1606240142
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:08:21 -0000

What is the probability of a sender (accidentally?)‎ generating a key that results in H being 0? 

Should a protocol check the H value and refuse to proceed (request re-generation) if H is 0?

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
From: Daniel Bleichenbacher
Sent: Friday, June 24, 2016 07:35
Subject: [Cfrg] AES-GCM-SIV security of the additional data
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.