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

Brian Smith <> Wed, 18 January 2017 23:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12908129410 for <>; Wed, 18 Jan 2017 15:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.58
X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, 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 RbNg6SvNwuiH for <>; Wed, 18 Jan 2017 15:46:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A40A1126D74 for <>; Wed, 18 Jan 2017 15:46:15 -0800 (PST)
Received: by with SMTP id 203so129321807ith.0 for <>; Wed, 18 Jan 2017 15:46:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=GQ11WW88rczSbfsdG6ygSJ3U7YSL5Be3b4JW0dNjkWA=; b=Uryu+mYmjUzqVd6Mkic88KBO1MRmpNoTrdESbS43loQzNS94PF1fbgjGj6/ke+u4vD v4Z3fOnhQsJVNFl6EINnqnfDIrMKhNkTaP0bbRv7RDyDcbbxTIJi/OFHajEA9MxexD1K 6Q1VDpT9khLNqRC8Ydvr7lEWAfUaMdLMEIUgQOROD/rGtG1vZuzprt7Zc5/BQQZg5UpY b4IZk/vP3AW40WI0jqqUaDKKPWDDQWSHYNThPhweS53jQhUVUjnXJ7gcLGvlQcThwWc4 opPLVp5+sMkk7VNrr4Gb1K66vKbHF73HiXX3RV3hGLTwDtGapp68utrHLvesBTvosb+m epvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=GQ11WW88rczSbfsdG6ygSJ3U7YSL5Be3b4JW0dNjkWA=; b=ZNx5NiRW4uP4uOX6Zh00RTQENRrYp9QoDH/2fwVVjSvIGxIqAulM3lxqmB40u3eaSI 2GUHyOYoqabObAUr2zJeGQ/PPZ22a8K9O1UvpDGd7PP8e8Dge2K5DaJoqhrfLb8Oth+s e/Tu2F/6O+OF0OxEdrBgx9ac0q5Vhi8XSmPSYn+g5WiMpAOgWYXZtna/4+GnX6CnYPVF E54vR+4Kiqp4lE4fiXFuBmZdhua0RgbjIRra4jPO/GxjGW+iDUzI7oZXvrF+IpqqCVxP qHZSyQ6hBucunbnjVA5qiQdqu+V1KUtkG7rKfukIibOO5IF6A/C3eifMqpDGQxTiWxRl 2Ftg==
X-Gm-Message-State: AIkVDXIhAqEHf8hxkRSdx4zhBEibi3rysCwsY4XEmunI7gvmxGnR4xM7vyTj+Te4YTEA+eP/84vmoX6BfAgmIQ==
X-Received: by with SMTP id m199mr5738347ita.117.1484783174893; Wed, 18 Jan 2017 15:46:14 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 18 Jan 2017 15:46:14 -0800 (PST)
In-Reply-To: <>
References: <>
From: Brian Smith <>
Date: Wed, 18 Jan 2017 13:46:14 -1000
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
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: Wed, 18 Jan 2017 23:46:17 -0000

> There's also a htmlized version available at:

The intro defines nonce-misuse-resistant AEADS as ones that are
safe(r) to use when "two distinct messages are encrypted with the same
nonce". However, in reality we usually don't care only about the case
where *two* (==2) distinct messages are encrypted with the same (key,
nonce), but rather we care about the case where *multiple* (>=2)
messages are encrypted with the same (key, nonce). In particular the
new draft makes a distinction between encrypting <2^8 vs >=2^8
messages with the same (key, nonce), not a distinction between 1 vs 2
messages with the same (key, nonce).

The practical motivation for POLYVAL is unclear. In an email message
in an earlier mailing list thread, Shay said "We chose to use POLYVAL
so that 128-bit blocks can be viewed as field elements and as AES
ciphertexts in a consistent way (with respect to the order of the bits
inside each byte))," and I think that this should be included in the
spec, along with a more plain explanation that this is done (IIUC)
simply to avoid byte byteswapping on little-endian systems that GHASH

It isn't clear how the nonce length of 96 bits was chosen. I can see
some advantages, e.g. it is more of a drop-in replacement for AES-GCM,
which is almost exclusively used with 96-bit nonces in IETF protocols,
but is there any other reason? Since nonce-misuse-resistance is not a
binary property, but rather a gradiant, it seems better to optimize
for minimizing the chance of accidental nonce misuse, or minimizing
the number of times a nonce is likely to be misused, which AFAICT
means choosing a nonce length that is as long as is practical. The
rationale in the other thread says "In order to make room for the
counter, the nonce size has been reduced to 96 bits," but the counter
for the key derivation only needs to be 3 bits long, IIUC, so it seems
like the nonce length was reduced more than necessary?

The email also said "We now generate keys by using counter mode and
discarding half of each ciphertext block." The motivation for
discarding half of each ciphertext block should be added to the draft
(maybe in security considerations), along with a reference of how
discarding half of each ciphertext block achieves that goal.

The draft makes an argument about safety when "nonces are selected
uniformly at random." However, isn't a key motivation for AES-GCM-SIV
our lack of confidence in our ability to select nonces uniformly at
random? I personally would like to see discussion of the case where we
can't assume nonces are selected uniformly at random. (While I can't
come up with one off the top of my head right now, it seems likely
that there would be simpler and less invasive ways of defining a
nonce-misuse-resistant AEAD based on AES-GCM if we can also assume we
have a good random number generator and we're willing to accept the
birthday bound analysis in the draft. Thus, based on intuition it
seems like AES-GCM-SIV must be useful in contexts where nonces aren't
chosen uniformly at random in order to justify its complexity.)