Re: [Cfrg] Second RGLC on "AES-GCM-SIV"

Yoav Nir <> Sat, 20 January 2018 19:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8273C127201 for <>; Sat, 20 Jan 2018 11:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 PVIt1rWKRzH8 for <>; Sat, 20 Jan 2018 11:10:26 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7965C120726 for <>; Sat, 20 Jan 2018 11:10:25 -0800 (PST)
Received: by with SMTP id g21so4448759wrb.13 for <>; Sat, 20 Jan 2018 11:10:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ZJdMsS1V0BQok+uDP936CZFGSxQMHFUkWMkgafMztC0=; b=Iore7mC5Exlpscgz8Phc8KYYWH0nYrPF4QqQyuaOoSZRTPkHMV6eeCrQhbsO4yPUHo TV+Si+kEx55ic0RMzNd+etJVIMYnmhu9xa+xLxM6AXzHKY0RIjUfOfOWeaCqhUvYrwT1 bstphtEkuyU2W8WzKNlTdNasffnnd8rlDaOYcmz8xAUMKU3XKJTDETzLkhxEMx3gVfkM g8xG6Isd5HrvVneLXdWhoeuty4546A+daL0UKwGl0CsmYE3evtpPFDr8neyWRtpmbKDa BxxFrv6Z1XQ1Q7hDHQtHA41r/4Z5005zA2jCgXeKNkwLz3jWVbhK+nRaopjKfsuY2ywX 9I4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ZJdMsS1V0BQok+uDP936CZFGSxQMHFUkWMkgafMztC0=; b=K2YePQj0dV+0VwpJWKBq8NlrE9NRg99kyAFazw3TcaVrbIismTQG8XJ/TCDF0+a0Z8 0UZNtMAYikiuKVrK2lj6qYjqc4AdFG04rs7mNvisuMauNeztwb0/Jg4TG3eO2SXkjI62 CpL2waSfvS8yVEg9sr3GcyV+b63uZEFalnUTsGazAZQE92SirIq9cIQS3wZIPxwMetDr kfjW/eDf+YsQBNqUwNEXysOZfgDkxxtgtIhfiKMZs01RK05QGb8IhXd0HAMqSi9NnlFy dJ57WqSOuo5PYV+qF6nBTb56WaQE/VyYsVCgH1QfFVn0sCRK5rqiX2Rm2KFlL+9jP4k4 nrqg==
X-Gm-Message-State: AKwxytehrTkFTRCX2c2j2FjkD8qhC07thaFAsYUx1xnWE4MDQ74aA768 eJtrgVsZCY8a1VMWtXRF8+I=
X-Google-Smtp-Source: AH8x225BOX6VV/4Wrcze1tQ7s3pIbX3xP4vBiRc9+kUEVnyCjUpuKGB6DbDwR1jQNjYT4VAKz59YPw==
X-Received: by with SMTP id h91mr2238333wrh.147.1516475423939; Sat, 20 Jan 2018 11:10:23 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id 72sm5177577wmh.44.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 20 Jan 2018 11:10:23 -0800 (PST)
From: Yoav Nir <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DEF7828E-129F-4364-A8CD-867CA7F9F1D4"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Sat, 20 Jan 2018 21:10:20 +0200
In-Reply-To: <>
Cc: "" <>, Adam Langley <>, Yehuda Lindell <>
To: "Paterson, Kenny" <>
References: <>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <>
Subject: Re: [Cfrg] Second RGLC on "AES-GCM-SIV"
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: Sat, 20 Jan 2018 19:10:28 -0000


The document looks good to me and I support publication.

CFRG documents are often used as input and reference to IETF document that will have names like “AES-GCM-SIV and its use in [protocol X]”.  For this reason they need to have some text explaining applicability. 

This document has one sentence at the end of section 1:

   We suggest that these AEADs be considered in any situation where
   there is the slightest doubt about nonce uniqueness.

I don’t believe that this is enough. IMO two things are missing:

The text should list some cases where there is such slight doubt. When there is a single encryptor for network traffic such as in TLS, IPsec and SSH, it’s easy for the encryptor to keep a counter and then there is no doubt that nonces are not repeated. So what are the scenarios where there may be such doubt?  I can think of two: multi-encryptor such as in multicast IPsec (RFC 6407), and cases where one or more encryptors encrypt and decrypt data across reboots such as for encrypting files or storage.

The other missing piece is what to do when nonce uniqueness cannot be guaranteed. The document has two things to say about this:
"we do not recommend using a fixed nonce as a policy”
"This also means that selecting nonces at random is a safe practice with AES-GCM-SIV”

I’d prefer a stronger statement:
“We suggest that these AEADs be considered in any situation where nonce uniqueness cannot be guaranteed” in the introduction, and
“Nonce uniqueness cannot be guaranteed but we would like to minimise collisions. To achieve this it is RECOMMENDED that nonces are randomly generated” - not sure where this goes.  Maybe in section 9 or maybe in the introduction.

The reason for this recommendation is that using a fixed nonce is bad, but using counters may lead to pairwise collisions between two encryptors, and that’s not ideal either. If we can’t do any better than recommending randomness is the best.  There is still the issue of encryptors having too little randomness. One approach can be to use counters with a random starting point if we can assume that the encryptors have 96 bits of randomness but not more, but I don’t think there’s a better general solution to poor randomness than the discussion at the top of page 12. I guess it will have to do.


> On 16 Jan 2018, at 18:32, Paterson, Kenny <> wrote:
> Dear CFRG participants,
> This message starts a second 2-week RGLC on "AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption" (draft-irtf-cfrg-gcmsiv-07), that will end on January 30th. See for the latest version of the draft.
> We are having a second last call because, although there only were small changes to the draft in going from 06 to 07, we also had the benefit of new security analysis on the draft:
> We also had some productive discussion on the benefits of using POLYVAL versus GHASH during the previous last call period, with the thread beginning at:
> Please send your comments, as well as expression of support to publish as an RFC (or possible reasons for not doing so) in reply to this message or directly to CFRG chairs. Your feedback will help chairs to decide whether the document is ready for review by IRSG and subsequent publication as an RFC.
> Thank you,
> Alexey and Kenny
> _______________________________________________
> Cfrg mailing list