Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt

Adam Langley <> Thu, 19 January 2017 00:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2CFE12941D for <>; Wed, 18 Jan 2017 16:13:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I6OeNiKOhHqp for <>; Wed, 18 Jan 2017 16:13:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AFB2F1293FC for <>; Wed, 18 Jan 2017 16:13:49 -0800 (PST)
Received: by with SMTP id j13so25615069iod.3 for <>; Wed, 18 Jan 2017 16:13:49 -0800 (PST)
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:content-transfer-encoding; bh=fXs15z9NDM7mPTu7z/PXBf6V5iQNwo0/vvQqEDBSX/c=; b=ln6APj4p2LRPW+RG/RhMx8mooPHaPmvaBz2z2MWLP8DdtD32O2JzA8B2qjhE9hRiY/ 1pS2T/VDOi1dqMsajBiN62IK3m5X4MibWGrq0SWymB/P/tlxUVxziSmMZbvPnicD13By qwgvCL+H5vRJTQ/eNRu626SLwNYSKYExBzJV0xA1LAp7jwRw/mCCEP2ZtC7LKIrfXTSK Uj3IELm0LHj0TSP9XlhiHueOL8TROGcGrocsAYsEpiphn21I/btootLFbIVpZBW0zAvm Z8NKmRPLQX0KYe6+RRaaSdDQUIo5imao6V3kQhE9bIx/sLN3aTB6IhQddX7eX5SrSIcQ MpaQ==
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:content-transfer-encoding; bh=fXs15z9NDM7mPTu7z/PXBf6V5iQNwo0/vvQqEDBSX/c=; b=TMsNA8sGKs+TQ1xpsGg3yWsY3AnGMJkhl6qLX4/fZRahiNEfGzqj0ltlmajTJ+53a1 i+Uei9n4KbeS0jL4zjknoE8Ko2kWaVh8yXFaACnCsEbgcMP5Y7YWF/hwND4L2dNKd7kH H1iIb+6xFm/L0YK1M8CvLf+ZCmx1P59zGGdMlsTqbbr6mKtN8MQcDSSaAz45TcDHGrrb qIGHr0WqkCaD1/MqfwCHP+saQpbAU1eThqf57WWJ8LLOT4YLcdkSF17Mv7ojIVNKxIgt nTe9+jcoZOiqo145rSTVu3udMZR7cezs8lZ1ble3n10CxPY9ItUc/YrD7vXDJduTrc7S DiQw==
X-Gm-Message-State: AIkVDXLyehGDBOBF/noLvkAkKoLku7hUiuJL7E4+tAqKIxBUne3wetajJsHyJDGAxU+cPMYW2LP3Z/4IcVzSSQ==
X-Received: by with SMTP id i36mr6135006iod.168.1484784828890; Wed, 18 Jan 2017 16:13:48 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 18 Jan 2017 16:13:48 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Adam Langley <>
Date: Wed, 18 Jan 2017 16:13:48 -0800
X-Google-Sender-Auth: oYhpFViWZnZEAeFr7Uv0PJxXnzg
Message-ID: <>
To: John Mattsson <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jan 2017 00:13:52 -0000

On Wed, Jan 18, 2017 at 1:05 PM, John Mattsson
<> wrote:
> - In addition to listing the performance penalty compared to GCM. The
>   draft should also mention that compared to GCM, some nice properties
>   disappear:
>   - Neither Encryption nor Decryption is online as encryption/decryption
>     cannot start before the whole plaintext/ciphertext is known.

I agree that this is true for encryption, but I don't believe that
AES-GCM should be *de*crypted in a streaming fashion, but rather that
records should be sized so that this isn't a problem. (At which point
the benefit for streaming encryption becomes small or moot.)

I've a long spiel about the dangers of processing unauthenticated
ciphertext which I'll spare you :) But, even for small machines, the
memory needed to safely buffer the decrypted plaintext to avoid
releasing it before it's authenticated is equal to the memory to
buffer the ciphertext followed by decrypting in-place.

So I actually quite like that the tag is at the end of the message
with AES-GCM-SIV because it makes it harder to do what I think is the
"wrong" thing.

>   - GCM-SIV removes the possibility to preprocess static headers (AAD).


(I wasn't sure where to put these points in the spec so, for the
moment, I've added an appendix for "Additional comparisons with
AES-GCM". I'm collecting changes in GitHub before making a new
version. For this message, see

> - “The result of the encryption is the resulting ciphertext (truncated
>    to the length of the plaintext) followed by the tag."
>   I suggest that the tag is placed first instead of last in the
>   ciphertext. This makes decryption online, which makes a large
>   difference. Suggestion:
>   “The result of the encryption is the tag followed by the ciphertext
>    (truncated to the length of the plaintext)"

(See above.)

> - "within 5% of the speed of AES-GCM."
>   Should state when this is the case, e.g. long plaintext/aad.


> - I think the draft should give performance data also for short
>   plaintexts/aad or even better list the performance in number of
>   operations:
>   GCM:
>     Block Cipher Operations = p + 1
>     GF(2^128) Multiplications = p + a + 1
>   GCM-SIV-128
>     Block Cipher Operations = p + 5
>     GF(2^128) Multiplications = p + a + 1
>   GCM-SIV-256
>     Block Cipher Operations = p + 7
>     GF(2^128) Multiplications = p + a + 1
>   (if I got it right...)

I think that's correct and I've added that to the new appendix.

>   Where p is the block length of the plaintext and a is the block length
>   of the additional authenticated data,
>   I doubt that encryption of short messages are anywhere near 5% of GCM.
> - The "++" and "[:8]" operation should probably be defined.


> - What it the security/performance tradeoff with truncation in the key
>   derivation? What would the security properties be if "[:8]" was
>   removed?

I'll have to let Shay answer this, but the rough idea is that, since
AES is a permutation, not two ciphertexts can be equal given that
we're encrypting different plaintexts using the KDF phase. However,
ideally we would want a PRF where outputs can be the same. By taking
only the first eight bytes of each ciphertext block, we better
approximate a PRF.

> - The definition of U32LE seems unnecessary and only adds complexity.
>   I suggest:
>     OLD "U32LE(3) ++ nonce"
>     NEW "03 ++ 000000 ++ nonce

Good point.

> - The term K1 is only used in Test Vectors. I guess it is an old term
>   that should be removed.


> Some editorials:

Thank you for all these. They should be taken care of.

> - OLD "The record-authentication key is 128-bit and the
>        record-authentication key"
>   NEW "The record-authentication key is 128-bit and the
>        record-encryption key"
> - "} else if bytelen(key-generating-key) == 32 {
>      record-encryption-key = AES128(key = key-generating-key,"
>   Should be AES256

Indeed, and record-authentication-key is wrong too!

> - Spacing around "+" and "*" are not consistent.
> - "the the"
> - yeilds
> - remainding
> - RFC7322 says "A comma is used before the last item of a series"

I think I've leave this one to the RFC Editor!