[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: @ietf.org
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.