Re: [Cfrg] AES-GCM-SIV security of the additional data
"Gueron, Shay" <shay.gueron@gmail.com> Fri, 24 June 2016 14:23 UTC
Return-Path: <shay.gueron@gmail.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 2A5DE12D7F8 for <cfrg@ietfa.amsl.com>; Fri, 24 Jun 2016 07:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VW13pJO-9hLK for <cfrg@ietfa.amsl.com>; Fri, 24 Jun 2016 07:23:53 -0700 (PDT)
Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 824EA128874 for <cfrg@ietf.org>; Fri, 24 Jun 2016 07:23:52 -0700 (PDT)
Received: by mail-wm0-x241.google.com with SMTP id r201so5425841wme.0 for <cfrg@ietf.org>; Fri, 24 Jun 2016 07:23:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:cc:date:message-id:in-reply-to:reply-to:user-agent :mime-version:content-transfer-encoding; bh=kcJh4SMIXYQ26KifDeSYvieeOWA6O3SMhg04kZvY8Tg=; b=bzZ4eTdpxPSnWOtfpX3B9rSijAVCCvZHBaN8+HDDfn1ltBNe1bapVYie/CvQhiOxgU qb3bkAF2H1Jc89Eke1cWVtq95u+9HJkN7ZeUHNtFmMTRsBsmU79gY2D8KeA/8Ufh3RiS llEzGoIOZ5c2ic6Yr7K7Kb8qZt27idzFc9hy4M5K1VvIN3JtenBqDiD6M1D4u4x/Zdfv HPHmt9iMT9Q307gQzrgtn8UOgmktoBuTBDOt9TIpJflSqui/XyVtiFRiKtVxK7xSVjFg i8DRxO1YXNOUfp8iXQ6C0wE5k0mpC0/2adBPMmXC8DJuZhi91HxiIWNKZTqWGOVrnWSv XoaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:cc:date:message-id:in-reply-to :reply-to:user-agent:mime-version:content-transfer-encoding; bh=kcJh4SMIXYQ26KifDeSYvieeOWA6O3SMhg04kZvY8Tg=; b=PsT0kZLiSFOwkkyUVHPG4biVJBf3nTse7+lbN4mHPcvZtl6TZ1i/k2Nk9tclP9pmBg NStb7FIdf2tp7P4W7DB5gYqNnq1+Ia3rhEHjxNlWeMsTu4uaHpr4BsSRhmSv6Ze1NzeQ qlZ1x/zTFJdivc/C/w0RaG7B5qCZqkYAnCvjZXLbGRjF9u4NOpfTbuu5GZW/eP67hPrt CW9O2h0lqwyLW7Hv/Yei1yxE2XJkWSruSGdjNhrIU6Rq8ADroxgqVsvThtFmtvVlwonH 1h27r1STPu8NGRhh65+7NktrSOgVvIzrNAADkDBbz0lXh6hF8gOcsuQ2nx18z0hXd/zy hBuw==
X-Gm-Message-State: ALyK8tKYy9cRpewzAW6P4/CfA1aVXd0SxtemuseoOQZrPU0lF1x1+I/VtKmUNyePNNJ3Cw==
X-Received: by 10.194.115.199 with SMTP id jq7mr4023458wjb.162.1466778230962; Fri, 24 Jun 2016 07:23:50 -0700 (PDT)
Received: from [10.0.0.3] (bzq-79-180-232-9.red.bezeqint.net. [79.180.232.9]) by smtp.gmail.com with ESMTPSA id a129sm3409058wma.2.2016.06.24.07.23.49 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 24 Jun 2016 07:23:50 -0700 (PDT)
From: "Gueron, Shay" <shay.gueron@gmail.com>
To: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>, Antonio Sanso <asanso@adobe.com>
Date: Fri, 24 Jun 2016 14:23:36 +0000
Message-Id: <ema3c568ce-b47f-45fc-b799-b78ad0494efd@sgueron-mobl3>
In-Reply-To: <D392F7AA.6EF93%kenny.paterson@rhul.ac.uk>
User-Agent: eM_Client/6.0.24928.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/qKJLMS_t8CiiSkPRbyhuD2KFK0k>
Resent-From: alias-bounces@ietf.org
Resent-To: <>
Cc: Yehuda Lindell <Yehuda.Lindell@biu.ac.il>, "cfrg@ietf.org" <cfrg@ietf.org>, Adam Langley <agl@google.com>
Subject: Re: [Cfrg] AES-GCM-SIV security of the additional data
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: "Gueron, Shay" <shay.gueron@gmail.com>
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 14:23:55 -0000
Hello to Daniel (and all) – This is a very interesting point, raised by Daniel. It does not attack AES-GCM-SIV, but rather a particular (imaginary) way to (not) use it. Daniel's demonstration shows that there exists a protocol that is safe (I guess) when using AES-GCM as a component, but not safe when (carelessly) using AES-GCM-SIV as this component. Indeed, so. But, as Daniel indicated, it does not violate the promise of AES-GCM-SIV, and the simple answer is: don’t use protocols (certainly not made-up) without proper analysis. To Kenny: it does not matter here if the there is a single key where a part of it are used for encryption, and another part for the authentication, or 2 separate keys. Because, the adversary controls this key (or the two keys) in the described scenario. About the protocol: if there is already a shared secret (S), why not use it directly with AES-GCM-SIV (where different nonces, that yield different encryption keys), as Kenny has already indicated. If someone insists on using such a hybrid protocol (why?), then how about this change in it: draw K1 and x uniformly at random, and define K1 as the encryption key, and K2 = ENC_S (x) as the authentication key. Then use AES-GCM-SIV with these keys and the mentioned protocol. This addresses the root cause for the protocol’s failure: now, the adversary does not control the authentication key and cannot force a “weak” (zero) one to be used. [disclaimer: I have not analyzed the protocol in depth] Thanks, Shay ------ Original Message ------ From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> To: "Antonio Sanso" <asanso@adobe.com> Cc: "cfrg@ietf.org" <cfrg@ietf.org> Sent: 6/24/2016 4:53:46 PM Subject: Re: [Cfrg] AES-GCM-SIV security of the additional data >Hi Antonio, > >On 24/06/2016 14:40, "Antonio Sanso" <asanso@adobe.com> wrote: > >>hi Kenny >> >>On Jun 24, 2016, at 3:24 PM, Paterson, Kenny >><Kenny.Paterson@rhul.ac.uk> >>wrote: >> >>> >>> In your scenario it looks like you are trying to use the shared >>>secret S >>> to provide authentication of the sender to the receiver, along with >>> confidentiality for the message being delivered >> >>to me this seems a pretty common scenario. >>If I am not completely wrong in my understanding is for example what >>JWE >>does [0] and [1] for example >> >>regards >> >>antonio >> >>[0] https://tools.ietf.org/html/rfc7516#page-32 >>[1] https://tools.ietf.org/html/rfc7516#page-36 > >Key transport via PKE using, for example RSA-OAEP, is a certainly an >option in JWE. But what Daniel describes has an additional symmetric >key >("S") for the purposes of authentication, I think, and does not >strictly >match anything I've seen in the JSON RFCs. But let's allow Daniel to >answer on that one... > >Cheers > >Kenny > >> >>> . In this scenario, it's >>> not clear to me why the sender and receiver would not just use S as >>>an >>> AES-GCM-SIV key to transport a session key K, and then use K in >>>another >>> instance of AES-GCM-SIV to transport the desired messages. Of >>>course, >>>this >>> construction would not prevent replay attacks; for that you'd need >>> additional mechanisms, like incorporating a counter into the AD of >>>the >>> key-transporting AEAD. >>> >>> But perhaps one should not underestimate the ingenuity of >>>implementers >>>in >>> wanting to use public key encryption. Is this where you are coming >>>from? >>> >>> On a related point, my view is that it is a disbenefit that the >>> AES-GCM-SIV proposal has two separate keys (one for encryption, the >>>other >>> for authentication) as inputs. That's not the AEAD interface that we >>>have >>> raised our implementers on. I raised this point at the CFRG meeting >>>in >>> Vienna back in May. Simply concatenating the two keys in the current >>> proposal into one would address this issue, but not the one you >>>raise >>>(if >>> I understand it correctly). >>> >>> (The minutes of the meeting can be found here: >>> >>>https://www.ietf.org/proceedings/interim-2016-cfrg-01/minutes/minutes-int >>>er >>> im-2016-cfrg-1) >>> >>> Regards >>> >>> Kenny >>> >>> >>> On 24/06/2016 12:35, "Cfrg on behalf of Daniel Bleichenbacher" >>> <cfrg-bounces@irtf.org on behalf of bleichen@google.com> wrote: >>> >>>> 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. >>>> >>>> >>>> >>> >>> _______________________________________________ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg >> > >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >https://www.irtf.org/mailman/listinfo/cfrg
- 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