[Cfrg] AES-GCM-SIV security of the additional data
Daniel Bleichenbacher <bleichen@google.com> Fri, 24 June 2016 11:35 UTC
Return-Path: <bleichen@google.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55CC612D878 for <cfrg@ietfa.amsl.com>; Fri, 24 Jun 2016 04:35:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level:
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLmSsqtxjveG for <cfrg@ietfa.amsl.com>; Fri, 24 Jun 2016 04:35:27 -0700 (PDT)
Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5D112D08D for <cfrg@ietf.org>; Fri, 24 Jun 2016 04:35:27 -0700 (PDT)
Received: by mail-vk0-x235.google.com with SMTP id c2so115825492vkg.1 for <cfrg@ietf.org>; Fri, 24 Jun 2016 04:35:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=RZkvRrwiX31qRLZwttdBUnCLWAkGv3NxH6fL8R3WTxQ=; b=VI+jLvGvdlcOVXv/B9MZnyBu5hhbHkl15lB8goB6Ab7llf5MEZRFrrIhhI1Iorn1/N cf3Ym6cSKvjYbUcHhw1NpV06GcdxwDa6vXBLydv8Tdb6oKEzapYHy8Br9IMNWFnCAMcZ MW68lQfTZQiRo0Ta5wHrSzzD4gJ28q7upcEspPL60ls1tUUW+LaD1cyF+tY5r7f/MI9k Ju8Jk7Nn1ges9LKVz2eFP6sIk5ueB+C7RzIDIR+pflwF6Tifb0Qn7R986al3pWQCzd1I OcBscWvqt4+lDxAzE4Py94nmoxp9CjmbePptg5gnAeinPD8by8Ti5p/KxAGwPiChr9zt +O2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RZkvRrwiX31qRLZwttdBUnCLWAkGv3NxH6fL8R3WTxQ=; b=AOM1wrDUANm1yVEgtCBN16NjjjdnMi3vTh/p9wywFevDCWVpHId0+xFaY1PpGSCAOC fCnI7yNb1hK+41IH4ESR4E1i7Yj9LvkDXJ51X77MefhHWJRk8QM5tD2jxOvPpGNivf6u +qh86SiM0hLzV/cD1otzdudaxsccIO1t1Bf63Nk8YPVgsBU7zSjsnn8R57YsRfBjYoGq wdRulxxoH8SmVBInSKEf+qPfAhegdS4+Ewi4BcefbP7Jj1bMfmGo1N3V1D9mFY14VrPq N0LdW2Pjtc9OzXjpkdxg0yXFJD5bZsurL+vt9slnO8R+o1wF3IJGSyMX+9ErZFeslLj3 cruQ==
X-Gm-Message-State: ALyK8tJdz/XRN0TdQV4Hilc0RYbuNnFFYAXcEijTFc1HayMlXe54StPhDfTUIpcnhYgLKlJ3FOIVFcwoPpyoUKZE
X-Received: by 10.31.205.131 with SMTP id d125mr1903021vkg.98.1466768125386; Fri, 24 Jun 2016 04:35:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.147.196 with HTTP; Fri, 24 Jun 2016 04:35:24 -0700 (PDT)
From: Daniel Bleichenbacher <bleichen@google.com>
Date: Fri, 24 Jun 2016 13:35:24 +0200
Message-ID: <CAPqF7e0QsCPn_OSKEry60Hm9F2BDU6DNG6Yc2NU=ocyCU2mwFg@mail.gmail.com>
To: cfrg@ietf.org
Content-Type: multipart/alternative; boundary="001a114e7102151602053604916d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/qgh-Yxmj7CC7cq2YZLpmfGA3x-o>
Resent-From: alias-bounces@ietf.org
Resent-To: <>
Subject: [Cfrg] AES-GCM-SIV security of the additional data
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2016 11:35:29 -0000
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.
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Paterson, Kenny
- Re: [Cfrg] AES-GCM-SIV security of the additional… Adam Langley
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Aaron Zauner
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Gueron, Shay
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Aaron Zauner
- Re: [Cfrg] AES-GCM-SIV security of the additional… Gueron, Shay
- Re: [Cfrg] AES-GCM-SIV security of the additional… Paterson, Kenny
- Re: [Cfrg] AES-GCM-SIV security of the additional… Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] AES-GCM-SIV security of the additional… Jim Schaad
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Blumenthal, Uri - 0553 - MITLL
- Re: [Cfrg] AES-GCM-SIV security of the additional… Blumenthal, Uri - 0553 - MITLL
- [Cfrg] AES-GCM-SIV with a new key hierarchy Gueron, Shay
- Re: [Cfrg] AES-GCM-SIV security of the additional… Gueron, Shay
- Re: [Cfrg] AES-GCM-SIV security of the additional… Daniel Bleichenbacher
- Re: [Cfrg] AES-GCM-SIV security of the additional… Paterson, Kenny
- Re: [Cfrg] AES-GCM-SIV security of the additional… Antonio Sanso
- Re: [Cfrg] AES-GCM-SIV security of the additional… Paterson, Kenny
- Re: [Cfrg] AES-GCM-SIV security of the additional… Blumenthal, Uri - 0553 - MITLL
- [Cfrg] AES-GCM-SIV security of the additional data Daniel Bleichenbacher
- Re: [Cfrg] AES-GCM-SIV security of the additional… Daniel Bleichenbacher
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Dan Harkins
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Shay Gueron