Re: [Cfrg] AES GCM SIV analysis

Alex Cope <alexcope@google.com> Mon, 30 January 2017 21:58 UTC

Return-Path: <alexcope@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 61B8F129638 for <cfrg@ietfa.amsl.com>; Mon, 30 Jan 2017 13:58:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.898
X-Spam-Level:
X-Spam-Status: No, score=-5.898 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=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=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 XJybkNdNHfGH for <cfrg@ietfa.amsl.com>; Mon, 30 Jan 2017 13:58:53 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 9617912962A for <cfrg@irtf.org>; Mon, 30 Jan 2017 13:58:52 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id b65so52936366wmf.0 for <cfrg@irtf.org>; Mon, 30 Jan 2017 13:58:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EyOSuxDT2GUg6L5NuAW6T2c5+wvc3NBUBHMbfhhy9cA=; b=bJKIe3UnqqGQo4KPgXN51uK8l2RDs9sTvF3rt8K0G23DUFwQ9sLyr/5EriH5nxOZah 7z/mqiC7ZjfmQaUVo5vtz1Fyfqhee1wUli4vOZe+aqJUZ9/B+TR0aTQ5/RLbRmqgvHnD iQb+ZFpEPpyAX6EAyPz0E+JaIZLFV+LA+2Pg0KZf5PGkEHMFSsaelNJBzLMVXB+4aFcc D5YCBdC13JxdPe7qOkD6WIh258i6NLIVSEPzC/ZOd+8hhn2zmiTp29slaAAmKHzhkOWo /6JudTMlTW3+PkVyXyOHJShe46GXCSZ+xSVZBYfgbkC/0OUObgRH85JRGXEV2nP+W1Bi wp3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EyOSuxDT2GUg6L5NuAW6T2c5+wvc3NBUBHMbfhhy9cA=; b=sMMiIZWcWp+ex+y9iaLqvqwThee692F6Rw84G9i3RwS31aKw3Cg1D+nngI3RBu4u57 lcxEhhXVgcd/K3oZDjVaYyqyGtTg2S9swXNqkJy/R4K5vkjeau4Z4+Y0LqnUrgV3O9Bx b6uZatOvMbvqKewad9CcmuvxfPpeGU7N3mEcSrlV1PZoAFUubNrZfVu52wsOCogjXIYw 1beRgB/nY+OUHQcaeaXDr4dSr8toqDWh41g227jBVkcY4BYHoGkziXph7kawp4FX+e8s xrOxJcOdVFwZIsAg9wPxv8jUOWwtkH3IJXCKEc9Q6/Mj1nvBk4MXUb9sOcr5dkN3siue vVvg==
X-Gm-Message-State: AIkVDXIyd4exK1x6pHYBvBQ6i9fbysFUhkDEMF4JY+F9kDMoYsmiJvMlxTamEjLwqsDmcLA676q7vxc4la4gz0FT
X-Received: by 10.28.64.132 with SMTP id n126mr17361147wma.107.1485813530709; Mon, 30 Jan 2017 13:58:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.149.73 with HTTP; Mon, 30 Jan 2017 13:58:50 -0800 (PST)
In-Reply-To: <CAMfhd9WoNeEbhWMbOHFMy9_Aq2XtU=Q3P7Bd6S8r3FsXT0N1mA@mail.gmail.com>
References: <D120A224329B7F4CA6F000FB5C0D964C01EBE26F73@MSMR-GH1-UEA07.corp.nsa.gov> <D120A224329B7F4CA6F000FB5C0D964C01EBE26F86@MSMR-GH1-UEA07.corp.nsa.gov> <D120A224329B7F4CA6F000FB5C0D964C01EBE26FEA@MSMR-GH1-UEA07.corp.nsa.gov> <CAMfhd9V77LN41QTt4YvNs-bjUan_PtdrEiQeHvKXY+G+k2z1kw@mail.gmail.com> <CAFewVt5VVpEKVGCt_c6UhG5sJ66xFfLUdOs4EZdnbgbTNPrFjA@mail.gmail.com> <CAMfhd9VNXAO=c2zw0UoVLDSL=BQL0JYVf8qVFLguoVv0ADsoWg@mail.gmail.com> <CAFewVt7kXyUcDATZ4yjvC0OOBE3-NLh9rGkHvLm1z4K9YQEBhg@mail.gmail.com> <CAMfhd9V05m3UtPae_PV5wUS63HHFRgRxF5m-UKfuTmzjYVDd+A@mail.gmail.com> <f6d2e9a7-4dde-efa7-ad9f-0e8dcd35b99a@lounge.org> <CAMfhd9WoNeEbhWMbOHFMy9_Aq2XtU=Q3P7Bd6S8r3FsXT0N1mA@mail.gmail.com>
From: Alex Cope <alexcope@google.com>
Date: Mon, 30 Jan 2017 13:58:50 -0800
Message-ID: <CA+cSK136NFr7gxzT1-fjDq9ZO5QGQR_67bZr1sCpL4KOTcoeDQ@mail.gmail.com>
To: Adam Langley <agl@imperialviolet.org>
Content-Type: multipart/alternative; boundary=001a114b2888b3a5b6054756eb24
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/wSHt1RQogQDv8qAxugUcNNNEyag>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] AES GCM SIV analysis
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: Mon, 30 Jan 2017 21:58:55 -0000

I'm also unconvinced that defining POLYVAL as modulo x^128 + x^127 + x^126
+ x^121 + 1 is better than defining it modulo x^128 + x^7 + x^2 + x + 1.

My reasons for thinking that  x^128 + x^7 + x^2 + x + 1 is a better
reducing polynomial are:
1) On X86, no performant implementation of POLYVAL will reduce to GHASH, as
that would result in unnecessarily byte swapping twice then calling
PCLMULQDQ. The same seems true for any implementation in a little-endian
machine.
2) If the concern is making a less performance sensitive implantation of
GCM-SIV easier to write given a GCM implantation, the relationship between
POLYVAL as currently defined and GHASH does help slightly. However,
implementing finite field multiplication with POLYVAL'S byte ordering
modulo x^128 + x^7 + x^2 + x + 1 given a reference GHASH implementation is
quite easy*, and most accidental errors in such implementation will be
detected by test vectors.  Thus I don't think the current design choice
makes GCM-SIV substantially easier to implement correctly.
3) x^128 + x^7 + x^2 + x + 1 is more 'natural' as as the lexicography first
irreducible polynomial.  It seems likely that future work that relies on
finite field multiplication will opt to use the byte ordering of POLYVAL
because it makes the most sense on little endian machines, and will also
reduce modulo  x^128 + x^7 + x^2 + x + 1.  I doubt anyone else will want to
use GHASH as currently defined, but if it were defined modulo x^128 + x^7 +
x^2 + x + 1, the implementation could be nicely reused. I think that in the
long term this will lead to more code reuse than having POLYVAL as a one
off finite field representation.

If you are strongly concerned reusing dedicated hardware or big-endian
implementations of GHASH then the current design makes some sense as a
compromise, but I'm unaware of such requirements.

Regards
-Alex

*I did it recently for a table-based implementation. You can look at the
patch here: https://patchwork.kernel.org/patch/9428397/

On Fri, Jan 27, 2017 at 12:21 PM, Adam Langley <agl@imperialviolet.org>
wrote:

> On Thu, Jan 26, 2017 at 6:26 PM, Dan Harkins <dharkins@lounge.org> wrote:
> >   But that is the definition used in the seminal work on the matter, [1].
> > If you want to have a different notion concerning a lesser restriction on
> > nonce reuse then you should use a different term.
>
> That paper formalises an advantage that an attacker might have over an
> ideal scheme. In the same way that block ciphers aren't ideal PRFs,
> nonce-misuse-resistant schemes aren't hitting that ideal either. RFC
> 5297 doesn't hit it, at minimum because it'll run out of counter-space
> after enough messages. AES-GCM-SIV isn't hitting it either.
>
> But that doesn't mean that they aren't practically useful.
>
> I'm not sure what an ideal NMR AEAD would look like, but it's probably
> quite different to both RFC 5297 and AES-GCM-SIV and probably looks
> like a wide-block construction. If someone can point at something they
> think does hit it, that would be interesting to me at least. (Although
> perhaps it's well trodden ground for those who are more familiar with
> the literature than I.)
>
> >   Which brings up a question I've resisted asking: Why are you doing
> this?
> >
> >   If you want to have an AEAD scheme that is nonce-misuse resistant that
> > can use a fast(er) authentication scheme then why not just do RFC 5297
> > with GHASH instead of AES-CMAC?
>
> AES-GCM has lead to a state of the world where our large machines,
> which need to encrypt and decrypt lots of data, end up having hardware
> support for AES and GF(128) operations. We would like to take
> advantage of that because it's hard to beat the speed and power
> efficiency of dedicated hardware, but sometimes we want not to have to
> worry about nonces.
>
> > You're defining a new irreducible
> > polynomial that, to my knowledge, is not in existing hardware the way
> > that PCLMULQDQ using x^128 + x^7 + x^2 + x + 1, is in Intel chips.
>
> PCLMULQDQ (and other hardware implementations, to my knowledge) is not
> specific to that polynomial. Also, the polynomial in AES-GCM-SIV is
> that polynomial, just with some ordering oddities addressed. See
> https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-03#appendix-A.
>
> > You're defining a(nother) KDF /inside/ the cipher mode itself instead of
> > just letting a KDF, which all users of AES-GCM-SIV will use, generate a
> > double-wide key. And I don't see the reason for either.
>
> Our KDF is per-nonce; it's not the same as having a double-width key
> and partitioning it internally. We do this in order to get better
> bounds when encrypting very large numbers of messages.
>
>
> Cheers
>
> AGL
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>