Re: [CFRG] draft-gueron-cfrg-dndkgcm-00 (Double Nonce Derive Key AES-GCM (DNDK-GCM) has been posted)

[Maximilian Lorlacks <[e-mail]>]

Hi Shay,

I'm glad to see that there is interest in an XChaCha-like construction for AES-GCM.  This has been kind of an open problem that I never knew how to fix myself and I hope that the CFRG will adopt this draft.

I've been unable to find a primary publication other than the slides of your presentation at RWC 2024.  I'm looking forward to the promised analysis paper.

A few notes on the draft itself. These came out a bit lengthier than I'd originally intended.

1. I am not sure how you authored this. The HTML and PDF formats still seem to reflect the state of xml2rfc before RFC 7990, which also seems to have given up on plain text as a primary source format in section 7.3. I assume you accidentally used xml2rfc, an outdated XML template or an outdated transformation pipeline.

2.1. Am I misunderstanding the second paragraph of section 3? "Let U be an array of bytes ("array" for short) of length u (bytes), written as U = U [u-1] U [u-2] ... U [0], where U [j] is the j-th byte, j = 0, ..., u-1." If U[j] is the j-th byte, but arrays start at zero, shouldn't U[j] be the (j+1)-th byte? U[0] is the first byte.

2.2. The inverse array ordering probably stems from GCM and AES being in big-endian traditions, but this will probably catch hasty implementers off-guard. This also does not appear to mesh well with the numbering established immediately before.

3. I'm not sure what happened in algorithm 2 or what itijbucgcinnvullehcrjdiheicn and cdbd are supposed to mean.

4. The notation of the For pseudocode is not consistently used with braces.

5. The operator \ne in algorithm 4 was not defined anywhere.

6.1. I find myself a bit troubled by the novel KC parameter. I would greatly appreciate guidance on how to treat the KC value. I assume it can be public, but how would this be ideally transmitted in a backward-compatible fashion? Appended or prepended to the ciphertext?

6.2. The document attempts to get IANA to make an entry in the AEAD registry, referencing RFC 5116. However, the interface specified in your draft mismatches the interface mandated by RFC 5116, section 2.1: "The authenticated encryption operation has four inputs, each of which is an octet string", namely the secret key K, nonce N, plaintext P and associated data A. Ignoring the different names, the encryption operation inputs are fine. However, the RFC 5116, section 2.1, says that the output is a sole ciphertext C. Your interface returns a ciphertext C, an authentication tag T and a commitment value KC. Similarly, RFC 5116, section 2.2, says that the authenticated decryption operation "has four inputs: K, N, A, and C". Yours has six inputs, K, N, A, C, T, KC.

7. Nit: In paragraph 2 of section 6, "non-repeating but nonrandom" uses the "non-" prefix once with and once without hyphen.

8. I'm unsure how I feel about the fact. This makes it difficult to unconditionally recommend as a safe alternative, leading to one more  for an implementer to make.

Cheers,
Max