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

"Blumenthal, Uri - 0553 - MITLL" <> Fri, 24 June 2016 18:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CE2512DCEA for <>; Fri, 24 Jun 2016 11:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.623
X-Spam-Status: No, score=-5.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 Nu-7oiRMvNrx for <>; Fri, 24 Jun 2016 11:03:19 -0700 (PDT)
Received: from (LLMX2.LL.MIT.EDU []) by (Postfix) with ESMTP id 940A612DCF9 for <>; Fri, 24 Jun 2016 11:03:17 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id u5OI0jrm042587; Fri, 24 Jun 2016 14:00:45 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: Daniel Bleichenbacher <>
Thread-Topic: [Cfrg] AES-GCM-SIV security of the additional data
Thread-Index: AdHOGXPgqD25y0zmskKltSj3U+rSKQAItLSAAAGYJQA=
Date: Fri, 24 Jun 2016 18:03:13 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha384"; boundary="B_3549621784_5115498"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-24_08:, , 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-1606240193
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 18:03:23 -0000

> On Fri, Jun 24, 2016 at 3:08 PM, Blumenthal, Uri - 0553 - MITLL
> <> wrote:
>> What is the probability of a sender (accidentally?)‎ generating a key that
>> results in H being 0?
> Random key generation is not my concern. My concern is a sender choosing a key
> on purpose in such a way that
> he does not have to authenticate additional data.

If our threat model is malicious sender that may try to “disown” his message
or deliberately allow somebody else to modify it – that same malicious
sender could covertly share his key and claim that adversaries guessed it
(highly improbable but not impossible).

> The typical assumption is that if an integrity check passes then the sender is
> aware of the plaintext. Should this also be the case for the additional data?

Probably not, if/when the sender deliberately makes it not so.


P.S. How easy is it to find such a key [that makes H = 0]?

>> From: Daniel Bleichenbacher
>> Sent: Friday, June 24, 2016 07:35
>> To:
>> 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
>> 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.