Subject: Re: [Cfrg] document shepherd comments on "AES-GCM-SIV"

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 3 Oct 2018 10:18:49 +0000

Dear Adam, Shay and Yehuda,

My apologies to you all for the long delay in producing a document shepherd review on the "AES-GCM-SIV" draft. 

My review is below.

Best wishes,

Kenny

----

Document shepherd review of draft-irtf-cfrg-gcmsiv-08.txt

Overall, the document would benefit from one more pass to discuss a number of minor issues identified below.

IANA: The document has IANA considerations: IANA is requested to add two entries to the registry of AEAD algorithms: AEAD_AES_128_GCM_SIV and AEAD_AES_256_GCM_SIV, both referencing this document as their specification..

Detailed comments (by page):

Page 1:

"that is easier to use correctly" - easier than what?
"most AEADs" --> "some AEADs including AES-GCM"
"when two distinct messages are encrypted with the same nonce" --> "when two distinct messages are encrypted with the same key and nonce"

Page 2:

"2/3rds" --> "2/3" or "two-thirds"
"POLYVAL like GHASH..." - this is the first mention of GHASH in the document, so add a reference or a parenthetical remark for the reader, e.g. "(the authenticator in AES-GCM)"

Page 3:

"for j = 0..s" -- should this be "for j = 1..s"? The first X_j is X_1.
"record-authentication and record-encryption keys" -- why use the word "record" here and throughout? The use is not restricted to TLS records, say.

Page 4:

After describing encryption, it might be helpful to add a note to say that POLYVAL is applied to an encoded version of the additional data and PLAINTEXT, in contrast to AES-GCM, where it is applied to an encoded version of the additional data and CIPHERTEXT.

"the first twelve bytes of S_s" - I'm not an expert on endianness issues, but is it clear which bytes these are (the pseudocode on page 5 clarifies, but the text should be unambiguous in its own right)?

"The counter advances by incrementing the first 32 bits interpreted as an unsigned, little-endian integer, with overflow." - the pseudocode on page 5 could be read as having no overflow, because there's an implicit cast to a 32-bit type in this snippet:

	block[0:4] = little_endian_uint32(
           read_little_endian_uint32(block[0:4]) + 1)

Please resolve!

"The result of the encryption is the encrypted plaintext (truncated to the length of the plaintext) followed by the tag" - counter mode as defined in NIST SP 800-38A, Section 6.5 includes truncation automatically as part of counter mode, so the parenthetical remark is strictly unnecessary. On the other hand, I didn't see a specific reference for counter mode in the document. 

Page 6:

In describing decryption, a mix of passive and active voice is used: "key are dervived", "then fail", "split the input". Please adopt a consistent voice. 

There is a significant implementation pitfall waiting in the decryption description: because the MAC is only checked after decryption, there is a risk that an implementation could release unverified plaintext to the calling application. Arguably, EtM constructions like AES-GCM do not suffer from this problem to the same extent. The security considerations section should explicitly mention this pitfall and the importance of avoiding it.

Page 9:

"Encrypting with the record-encryption key gives the tag, which is 4fbcdeb7e4793f4a1d7e4faa70100af1."

"Encrypting this with the record key gives the first block of the keystream: 1551f2c1787e81deac9a99f139540ab5."

- in both cases, for clarity, add "using AES".

- "AES-SIV" - is this what is specified in https://tools.ietf.org/html/rfc5297? If so, add a reference, likewise for AES-CCM?

- "the adversary has an advantage of 1/2" - here you should make it clear what kind of adversary you are talking about, e.g. "a distinguishing adversary trying to break the confidentiality of the scheme".

Page 10:

"when nonces repetition is low" --> "when nonce repetition rates are low"

"it is RECOMMENDED that nonces be randomly generated." -- add something like "for use in AES-GCM-SIV", as you are not making a general recommendation for all of cryptography here!

"(for these bounds, the adversary's advantage is always below 2^-32)" - same above, text needs to be more precise about which kind of adversary we are concerned with here - is it a general AEAD adversary from the all-in-one security notion of Rogaway-Ristenpart, or one focussed on breaking confidentiality via a distinguishing attack?

"For up to 256 repeats of a nonce" -- >  "For up to 256 uses of a nonce with the same key"

"this assumes a short AAD" -- how short? Please be more specific. Also, this is the first use of the acronym in the document; please introduce it properly.

"In fact, nonces repeat far less than 256 times when randomly chosen." -- well, that depends on how many nonces you generate - if you generate enough, then they certainly will repeat this often! Please be more precise here, or just remove this sentence and the following "Thus,".

Page 11:

"Theorem Seven in the paper" --> "Theorem 7 in [ref]" and complete the reference.

Again how short is the AAD here?

"We also wish to note that the probability of successful forgery increases with the number of attempts that an attacker is permitted." --  integrity is treated relatively cursorily here. Please consider adding further detail, e.g. provide some concrete numbers like you did previously (this text also hints that the previous numbers were all for an adversary against confidentiality, reinforcing the point that a bit more discussion/definition is need when first introducing adversaries).

Page 15:

"Some, non-security, properties" --> remove commas. Maybe just say "functional" instead of "non-security"?

"2/3's" --> "two-thirds of"

Appendix C: I have not checked the test vectors.