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

"Dang, Quynh (Fed)" <> Mon, 23 January 2017 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 260F1129785 for <>; Mon, 23 Jan 2017 10:43:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3dxsmaOMHyY0 for <>; Mon, 23 Jan 2017 10:43:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 278F412978B for <>; Mon, 23 Jan 2017 10:43:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7CEqBvlg/Mrt8cBEwYRbwROxBk+eygfnpQvBkGyTY+c=; b=YOA98mfedfkffhHSoEJLwR0qwBpoorG6mw8WwJ/YfIK0lfjj+4mBIMwrh3Xa7dpH/a4H47r8zzMMpyzlWMYsIHjSPMXC36WyneeqoVk2YBcUW5ruBqvu9xyJZV1Y6NrzZfQRD6117PQSvC3W4SlERSBgc3B1gRxz6T/vte/KJNg=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 18:43:03 +0000
Received: from ([]) by ([]) with mapi id 15.01.0860.021; Mon, 23 Jan 2017 18:43:03 +0000
From: "Dang, Quynh (Fed)" <>
To: "" <>, "" <>, "" <>
Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt
Thread-Index: AQHScbCZ8kiCS1OYRESvPWcqhnCpe6FGDyat
Date: Mon, 23 Jan 2017 18:43:03 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: f1d6ff19-9cb6-46bf-88de-08d443bfa9f2
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR09MB1462;
x-microsoft-exchange-diagnostics: 1; CY4PR09MB1462; 7:wrmPRy3HjdlswYKzQ3/MR0/eMhjMS5hEumOpRD5DB82g9NJwv/hX4R4P8IUiG86aGdcxe0MNsbRObPcC43aKEWFCc0BDBVLYOsf8m613qo02AW/hRDC+08B20DbaCjJC8GzHEOM5oIO9HivmY3r0k5xu+RuKiMFz6/Wq0RHI1CSuOIm9kLtkkrPm2TCW2rWtqTa12WfyGLIoPttTZT9tkB7jOo3ke+tqnC+juHxa+uLAHxTHWRLufRGWgvUixj0tKz06rsEdvKM9QA7B0DHrGPr8Nd2caiCrk8OxI35Bmc5gpQNEUL+mB9YuMLU7fS6ueZU5zSxP7b6Ok+30MiPGRmdbn1ukb44r4h4C+fSK1u2vdeOZkYv3oD/eZACtJD/YoGvivv/JvElz9ztrJkq8HWEKAF3Pv2GeqkmOdjxcTzq0u7pxIJHXbeZCVRPo6GsNPoQoDiWe84Qr6066y7o47w==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:CY4PR09MB1462; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1462;
x-forefront-prvs: 0196A226D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(377424004)(189002)(377454003)(199003)(606005)(236005)(66066001)(105586002)(6436002)(122556002)(106356001)(2900100001)(19627405001)(54906002)(99286003)(229853002)(55016002)(106116001)(8936002)(54896002)(53936002)(54356999)(25786008)(6306002)(9686003)(2201001)(81166006)(81156014)(33656002)(50986999)(189998001)(5660300001)(8676002)(86362001)(5001770100001)(101416001)(7696004)(2501003)(3280700002)(97736004)(77096006)(3846002)(2950100002)(230783001)(6606003)(76176999)(6506006)(68736007)(6116002)(4326007)(2906002)(102836003)(7736002)(38730400001)(7906003)(8656002)(74316002)(92566002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1462;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR09MB14647145E97FF7B14C558749F3720CY4PR09MB1464namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2017 18:43:03.3800 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1462
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: Mon, 23 Jan 2017 18:43:07 -0000

Shay, Adam and Yehuda,

There are 2 things I hope to discuss in this email below.

1) The draft said that "We recommend a limit of 2^50 plaintexts encrypted with a given key. Past this point, AES-GCM-SIV may be distinguishable from an ideal AEAD.  (This is based on standard assumptions about AES.)".

To keep the probability of having a collision among 128-bit blocks in the ciphtertexts below 1/2^32 (practically zero), it has been suggested that under a given key, the amount of ciphertexts is not more than 2^48 128-bit blocks for the GCM in TLS 1.3.

With 2^50 plaintexts (equivalent amount of ciphertexts) and each ciphertext can be up to 2^32 128-bit blocks in the GCM-SIV draft, there can be collision situations.

A. When the ciphertext size is only 1 128-bit block, the probability for a collision is already higher than 1/2^32.

B. The probability for a collision gets bigger when the size of a ciphertext gets bigger.

With the GCM-SIV, the collision issue is under multiple AES encryption keys when the corresponding nonces are unique which is different from the collision situation described at the beginning for the GCM in TLS 1.3 which is under only one key.

I can't think of a damage to the data owner who sends their encrypted data over a TLS session caused by collision(s) among 128-bit blocks of the ciphertexts. So, I don't have an opinion here.

2) The draft said that " However, we feel that the 2^32 limit for AES-GCM is too risky in a multi-key setting.  Thus with AES-GCM-SIV we recommend that, for a specific key, a nonce not be repeated more than 2^8 times.  (And, ideally, not be repeated at all.)" .

Currently, the GCM with 96-bit random nonces situation, NIST requires the number of encryptions to be not more than 2^32, so that the probability of a repeat of a pair (key and nonce) is below 1/2^32, under a given key.

With m keys, the probability for a repeat of a pair of (key and nonce) is about m/2^32.

Therefore, it is best to use  96-bit counter-nonces for GCM.

With the GCM-SIV, when a nonce is repeated 2^8 times, the AES-128 encryption key is repeated 2^8 times. The 96-bit nonces for the AES counter mode encryption are practically (pseudo)-random nonces (derived from plaintexts and the master key). The probability for a repeat of a pair of (key and nonce) is about 2^16/2^96 = 2^(-80).

If someone cares about the multi-key situation such as the amount of keys being 2^50 (2^50 sessions),  call the number of sessions 2^x, the probability for a repeat of a pair of (key and nonce) is about 2^(x - 80).

The actual break happens when a pair of (key and nonce) repeats AND at least one 32-bit counter value also repeats with this pair. This problem happens  with 100% chance when the ciphertext size is (2^31 + 1) 128-bit blocks or larger.

Call the size of a ciphertext 2^y 128-bit blocks, the probability for having at least one 32-bit counter value to repeat is about 2^(y + 1)/2^32 = 1/2^(31 - y) = 2^(y - 31).

So, the number 2^(x - 80) x 2^(y - 31) = 2^( x + y - 111) must be not greater than 2^(-32) in order to keep the probability for a complete break to be below 2^(-32).

2^( x + y - 111) <= 2^(-32)   <==>  x + y <= 79.

When y = 32, x <= 79 - 32 = 47.

So, when plaintext/ciphetext size is 2^32 128-bit blocks, the GCM-SIV might be not good enough for 2^47 (or more) sessions when each session has 2^8 repeated nonce if a user's objective is to protect all of those 2^47 (or more) sessions.

In short, this condition "x + y <= 79" should be respected for the current GCM-SIV: draft 3 when the mode is used to protect a large number of sessions (multiple users).

To protect a lot more than 2^47 sessions when the ciphertext size is about 2^32 128-bit blocks, maybe it would be good to require that nonce must not be repeated. A specific number of repetitions of a nonce allowed can be derived from each pair of x and y if desired.



From: Cfrg <> on behalf of <>
Sent: Wednesday, January 18, 2017 12:30:31 PM
Subject: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Crypto Forum of the IETF.

        Title           : AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption
        Authors         : Shay Gueron
                          Adam Langley
                          Yehuda Lindell
        Filename        : draft-irtf-cfrg-gcmsiv-03.txt
        Pages           : 45
        Date            : 2017-01-18

   This memo specifies two authenticated encryption algorithms that are
   nonce misuse-resistant - that is that they do not fail
   catastrophically if a nonce is repeated.

The IETF datatracker status page for this draft is:
draft-irtf-cfrg-gcmsiv-02 -<>
AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption (Internet-Draft, 2016)

There's also a htmlized version available at:

A diff from the previous version is available at:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at

Internet-Drafts are also available by anonymous FTP at:

Cfrg mailing list