Re: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06

Adam Langley <> Mon, 18 September 2017 19:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1E621321D8 for <>; Mon, 18 Sep 2017 12:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T1IlJp3IF0MX for <>; Mon, 18 Sep 2017 12:41:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 637721243F6 for <>; Mon, 18 Sep 2017 12:41:54 -0700 (PDT)
Received: by with SMTP id 7so693947pgd.13 for <>; Mon, 18 Sep 2017 12:41:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2N/tsTR245sBMWprylI3dUGfj6MMCJz/pFgrx/PDQVs=; b=Cjm9CSgbbDU+xMOYT3rG5o4Ae2abJrYnN/xcGGG2rCybTQvpx0JWdpa3CCUTbCbKwM 9hCyEcVQsQ2f/MxZK6PMlG9Mff9JRIR1Qrlq41bYeU+9fC+qgsc4cc10p6ld49MbBhmy YultE5IhnCkjLoGeGVX6W/+SuBCeILy/xWLnOCgWF8P9400noiwHMLMi2YZbJtCHCffC i36N3FZH9TiV2miOdqubK8/EJ8rZKkx9QFmRf7yJWvHE2xMiiL8+zo347O8QW/h115rZ MiTVz7UQwf4Y8GrsZZq2x4jCBb/RXMKOIh4r7wwAhVAuQgaxqQ8BCXtrCi3KP2afgLBa mClg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2N/tsTR245sBMWprylI3dUGfj6MMCJz/pFgrx/PDQVs=; b=qEDWXnnEDq5NKEoM8zAs3cgTy2PU31imKUbuIQim8+BLQ7/hJEu6qmopj0DbIZfV30 BehAPhHuPKCi4C9jmY7D5QIRpqKALTZtCeiCTqaStdPzpL9/5wtQlX95z2TZeKg+FFOx aMmv+scoj1jaInONykLJV4rRSPRfi2vCSAE4oYHDowixIP3t48EDb89b6oqZj/IcuMPP LxqW5VyIzYauNkhU7XbtD8QQ7arzOKR3a/2EZjT+sa+3gFm4Lxj3IklYeFWVffajgzJY S21VhBiB3ffCkvgMRnoJR1yc3hM0W+wx/sgw8BKsLTFK1jllcc9pEsJQtxHfLvG8luDS GvAw==
X-Gm-Message-State: AHPjjUh7YSzCHXrLegAf8uCS1LMOQQPZJd8gyUdz+GcKmTp0ygbJIjrn 4LTGgFR9RNYxEWqlcd9BeyFN4jc33hDy6Do4l74=
X-Google-Smtp-Source: ADKCNb7Y31tdN+hg+p575JWcr98NCVxvl0DOHjcpEcb6OYkfrvjRnmUdTNWEO9aTXpcTD6jrEu9PTgIO80gsOrGbfTA=
X-Received: by with SMTP id y25mr33202279pgc.45.1505763713817; Mon, 18 Sep 2017 12:41:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 18 Sep 2017 12:41:52 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Adam Langley <>
Date: Mon, 18 Sep 2017 12:41:52 -0700
X-Google-Sender-Auth: 6HoWJYeUTZD8Sfr1QP71YdCDfkU
Message-ID: <>
To: Andy Polyakov <>
Cc: "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Cfrg] RG Last Call on draft-irtf-cfrg-gcmsiv-06
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 18 Sep 2017 19:41:56 -0000

On Mon, Sep 18, 2017 at 10:51 AM, Andy Polyakov <> wrote:
> Well, it's not like I actually reject the sentiment to favour
> little-endian platform[s], question rather is if *mode* specification is
> right place for it. Protocols are about *communication* and there are
> more factors in play, most notably using already available primitives
> would facilitate adoption. And if little-endian-centric primitives are
> deemed desirable, wouldn't it be more appropriate to define them
> separately to promote modularity and re-usability?

Anyone who has implemented GHASH has had to wrestle with the
specification's handling of bit ordering, it's confusing beyond
questions of little- vs big-endian.

But it's also the case that little-endian machines now dominate. It's
nice that some big cores can largely hide the cost of doing the byte
swap, but hiding work is not the same as avoiding it (as your Skylake
numbers show) and smaller cores may not be able to do the
out-of-order, superscalar magic needed. POLYVAL is GHASH done right
for the world as we find it.

As for diversity: that's a cost. Although it's smaller here than in
many cases. Where the diversity costs really bubble up is when they
spread up the stack and we have, say, RSA-with-SHAKE128 to test and
validate everywhere. I think the diversity cost of AES-GCM-SIV is
concentrated in its very existence (i.e. that it's not AES-GCM). For
cases where AES-GCM-SIV isn't being written as a stitched asm blob
(where the full implementation cost of either POLYVAL or GHASH is be
paid anyway), BoringSSL uses the mapping to GHASH to avoid another
implementation, as specified in the draft.



Adam Langley