Subject: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-01.txt

From: [email-masked]
Date: Mon, 09 May 2016 05:23:58 -0700

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-01.txt
	Pages           : 95
	Date            : 2016-05-09

Abstract:
   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:
https://datatracker.ietf.org/doc/draft-irtf-cfrg-gcmsiv/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-irtf-cfrg-gcmsiv-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-cfrg-gcmsiv-01

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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Adam Langley <[email-masked]>
Date: Mon, 9 May 2016 05:33:05 -0700

> This draft is a work item of the Crypto Forum of the IETF.

Dear all,

In light of discussions here we've changed the way that AES-GCM-SIV
works with AES-256. It wasn't the case the two equal plaintexts with
consecutive nonces would produce equal ciphertext. However, it seems
to be insufficiently clear, and masking off a bit from the nonce
(i.e., 127-bit nonce) looks inelegant.

Thus, the record-encryption key is now generated using the "OFB mode"
suggestion made by Uri Blumenthal. (Thanks to him for that.)

In addition, we changed the initial counter value to avoid setting the
least-significant 32 bits to zero. Starting the block counter at zero
reduced the security margin in the analysis, and we realised that
there was no reason for it.

Cheers

AGL

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Mon, 9 May 2016 14:09:18 +0000

Hi Adam,

Deriving a record encryption key from a random nonce (hopefully a new nonce) aims to make it a fresh record encryption key for every encryption call under a given encryption key.

The freshness of record encryption keys solely depends on the uniqueness of the nonces.  This situation can be improved without any additional cost by deriving the record encryption key from the POLYVAL value S_s and the nonce.  Therefore, as long as the message is new, the record encryption key is expected to be fresh regardless of whether the nonce is fresh or not.

In Sections 8 and 9, the text talked about random nonce. It should be clearly explained that counter-nonces are as good as random nonces: only the uniqueness of the nonces under a given key is desired.

Regards,
Quynh.

P.S: My discussion on this topic is my personal curiosity of technical details and does not necessarily represent any views of my employer.
________________________________________
From: Cfrg <[email-masked]> on behalf of Adam Langley <[email-masked]>
Sent: Monday, May 9, 2016 8:33:05 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-gcmsiv-01.txt

Dear all,

Cheers

AGL

_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg