Subject: [CFRG] Comments on draft-denis-aegis-aead

From: Neil Madden <[email-masked]>
Date: Thu, 24 Mar 2022 14:44:31 +0000

I took a look at the latest AEGIS draft (https://jedisct1.github.io/draft-aegis-aead/draft-denis-aegis-aead.html). 

Overall, I think AEGIS is very interesting and as a high-performance alternative to AES-GCM with fewer sharp edges, I hope that it sees wide adoption. A CFRG publication would encourage that, so I support it moving forward.

Some comments on the current draft follow. My comments are largely editorial in nature - I find the technical description of the algorithm itself clear and easy to follow.

Section 1:

It would be good to add an explicit reference to the CAESAR competition (is there some kind of final report?), and to mention that AEGIS was selected for the high-performance scenario. Also, as I mentioned previously on Reddit [1], some readers may be surprised that this draft only describes the -256 and -128L variants of AEGIS, when it was the -128 variant that was selected by CAESAR. I understand and agree with the rationale for this, but it does put the draft somewhat at odds with the competition result that it is citing as a motivation.

On a related note, I can see how it happened, but on first reading it seems really weird that we have a 128L variant that has 128-bit security levels for everything but uses 256-bit “blocks", and then a 256 variant that has 256-bit security levels for everything but only 128-bit blocks. (The distinction between input blocks and AES blocks is generally confusing - perhaps an alternative term like “chunk” could be used for input blocks?). I would perhaps be inclined to simplify things even further and only document the AEGIS-128L variant, which seems like the best pick of the three for the intended use cases.

The discussion of partitioning oracle (PO) attacks could be moved from the introduction to a later section (perhaps section 6), with perhaps just a short note in the intro that AEGIS is key-committing and therefore resists partitioning oracle attacks. It doesn’t seem like resistance to PO attacks is the primary motivation for the new cipher. The discussion of PO attacks itself seems to almost imply that AEGIS is safe to use for encryption directly with a password as the key - it may not be obvious to some readers that use of a suitable password-based KDF is implied in this case. I suggest changing the wording of this to something along these lines:

  One example where the key-space may be small is where the key has been derived from a password, using a suitable password-based key derivation function. In this scenario, an attacker can guess a large number of passwords at a time ...

"While this may be mitigated by means of inserting a padding block in the aforementioned algorithms” - it’s not clear to me what this is referring to. Perhaps add a reference if this is a known mitigation technique?

Section 3:

I appreciate the in-line security considerations. In this note the draft says:

   The nonce MUST NOT be reused under any circumstances; doing so allows an attacker to recover the internal state.

While the introduction says:

   Finally, unlike most other AES-based AEAD constructions, such as Rocca and Tiaoxin, leaking the state does not leak the key.

So what is the implication of leaking the state? In GCM nonce-reuse allows (among other things) recovery of the MAC sub-key and subsequent forgeries. What is the impact on message authentication of nonce reuse?

The security considerations (section 6) says:

    Both algorithms MUST be used in a nonce-respecting setting: for a given key, a nonce MUST only be used once. Failure to do so would immediately reveal the bitwise difference between two messages.
Does this mean that there is no impact on integrity, but only to confidentiality? (Also the “for a given key” caveat is missing from the note in section 3.1 and should probably be added).

In section 3.2 (and 4.2), the requirement to compare the MAC tag in constant time is only a SHOULD. I can’t see any good reason not to make this a MUST given how simple it is to implement?

The technical description of the algorithms is very clear. I haven’t implemented them, but I am confident I would be able to based on the draft.

Section 5:

I’m not really sure what the purpose of this guidance is for. JOSE encodes the ciphertext and tag into a single string, but doesn’t just concatenate them  as suggested - does that mean a JOSE implementation of AEGIS would be non-compliant, or would you consider the JOSE components to be distinct structures? The same for COSE too I guess.

Section 6:

This appears to be the first mention of “context-committing”, which I think should be defined if it is an important property (it’s new to me).

Given that AEGIS is key-committing, I wonder if in fact it only needs to be target collision-resistant to be compactly committing? That is rather than finding an arbitrary (k1, m1, ad1) and (k2, m2, ad2) pair that produce a colliding authentication tag, an attacker would have to commit to a single key, k, and then find (m1, ad1) and (m2, ad2) pair that produce a colliding tag under that key? If so, that would mean that the 128-bit tag length does not completely rule out AEGIS from being compactly committing, but I’m not really qualified to answer this question.

As mentioned earlier, it would be good to explicitly spell out the consequences of nonce reuse in this section.

Are there any gotchas in AEGIS with regards to quantum adversaries, or can I assume that the 256-bit variant is basically immune as far as we know?

[1]: https://old.reddit.com/r/crypto/comments/qgc2o3/the_aegis_family_of_authenticated_encryption/hi67879/ 

Kind regards,

Neil Madden

---

From: Neil Madden <[email-masked]>
Date: Thu, 24 Mar 2022 17:13:16 +0000

> On 24 Mar 2022, at 14:44, Neil Madden <[email-masked]> wrote:
> […]

Answering my own question on this specific part, after revisiting the definition of TCR - no, TCR doesn’t apply in this case.

— Neil