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

[Brian Smith <[e-mail]>]

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

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
requires.

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.)

Cheers,
Brian
--
https://briansmith.org/