Re: [Cfrg] AES-GCM-SIV security of the additional data
Daniel Bleichenbacher <bleichen@google.com> Fri, 24 June 2016 13:17 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 E6C2612DA9A for <cfrg@ietfa.amsl.com>; Fri, 24 Jun 2016 06:17: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 wf1JNHgnZ--U for <cfrg@ietfa.amsl.com>; Fri, 24 Jun 2016 06:17:27 -0700 (PDT)
Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (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 DFB7112DA9D for <cfrg@ietf.org>; Fri, 24 Jun 2016 06:17:26 -0700 (PDT)
Received: by mail-vk0-x22e.google.com with SMTP id c2so119383706vkg.1 for <cfrg@ietf.org>; Fri, 24 Jun 2016 06:17:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kz9cPOv5fg5rsOh+NAJO0jt6p8zawhf4HP0Mm8hYOhY=; b=QVTaXk4FKuuf+IbSsjrKuYuUCyxB0t4tdRJYcRm1d+4b41QNBHCikZGSD/zxkfzE9P ip1fyB3BwiofzGIpKpAvSKo87iPGHMryiZsIENZ9MNK7u2b7cysga5F/vIeZMtm2p0aM 5XcM8SpnCxaym/MQ7WCHKqbLKJWwqUAx/ATWWMMRNuU6vUB400gUPX8rwUkwn/2c3Vvk SlqEmdplTzMJjmPjxVqB7L1NWevysZj5YkfbEvIf5r4+6x997OKzWkXO6rFhqY3qHWBw ou0aGS4J6JI7XZlLuMhHQPrxy0IqAsLTOesFb0fW+jpp84CghmgH8dlW0nDIlTlST4w3 OPAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kz9cPOv5fg5rsOh+NAJO0jt6p8zawhf4HP0Mm8hYOhY=; b=daumxsaVGL+w16CcIpQuVo6iTS6SwO4ud2pEg1C3dgcpyBpZ5hryMiHmz8wZvQ0Wdf LQrTgo1w8hrmcZ0I8LwPitgsUWVEfKquORlbhUy9UW6Y0SRTqSoqu0dU2Frz4IbFyP0j IUcOJyh/8j2kxURJ5csLVoPqO5Bm+PGKo9Y81GobD+9AZV8Gy6NGBXeuUzQLAQAbeAlN s2PwfgEsRCLPfcBalne93lddqPYa1uc5K2hIJWNQ1opiFtIMdXGdgBWHjbRMn6yihtFh rahf5iSt/EO1Cngz+omNslxaD33uPYFctxbuT1ywiLW8SAI2BDMRsOlk9Q9cD1AMTFUZ drug==
X-Gm-Message-State: ALyK8tJ0GdXth/krRFkxCKoq/Ixvy23BNyxqqUASu6avSfw6nSAwiOaYALie9+gedp1msCKEtpIpOHFvTAoreAQ2
X-Received: by 10.159.55.235 with SMTP id q98mr2316976uaq.83.1466774245676; Fri, 24 Jun 2016 06:17:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.147.196 with HTTP; Fri, 24 Jun 2016 06:17:25 -0700 (PDT)
In-Reply-To: <20160624130816.18296913.43011.75951@ll.mit.edu>
References: <20160624130816.18296913.43011.75951@ll.mit.edu>
From: Daniel Bleichenbacher <bleichen@google.com>
Date: Fri, 24 Jun 2016 15:17:25 +0200
Message-ID: <CAPqF7e0Ov=wGimBu8ggKJeLXueHmpbsqgxYg-w8fveUX1Sm0JQ@mail.gmail.com>
To: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
Content-Type: multipart/alternative; boundary="94eb2c04004ce180d0053605fd27"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/yU4M_3EyD6Ouvc98ftIagYB4-_0>
Resent-From: alias-bounces@ietf.org
Resent-To: <>
Cc: "cfrg@ietf.org" <cfrg@ietf.org>
Subject: Re: [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 13:17:30 -0000
On Fri, Jun 24, 2016 at 3:08 PM, Blumenthal, Uri - 0553 - MITLL < uri@ll.mit.edu> 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. 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? > 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 > *To: *cfrg@ietf.org > *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. > > >
- Re: [Cfrg] AES-GCM-SIV with a new key hierarchy Paterson, Kenny
- 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… Adam Langley
- 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