Subject: Re: [CFRG] [RFC] AEGIS

From: Soatok Dreamseeker <[email-masked]>
Date: Wed, 2 Mar 2022 02:10:16 -0500

Hi Frank,

At the bottom of section 3.1, I observe the following:

   msg_blocks = Split(Pad(msg, 256), 256)
   for xi in msg_blocks:
       ct = ct || Enc(xi)

   tag = Finalize(|ad|, |msg|)
   msg = Truncate(msg, |ct|)

Should this last line be `ct = Truncate(ct, |msg|)` instead?

I also observe that the congruent truncation isn't specified for AEGIS-256,
only AEGIS-128L.

   msg_blocks = Split(Pad(msg, 128), 128)
   for xi in msg_blocks:
       ct = ct || Enc(xi)

   tag = Finalize(|ad|, |msg|)

Above: No Truncate().

Under Section 6 (security considerations), I observe the following:

   With AEGIS-128L, random nonces can safely encrypt up to 2^32 messages
   using the same key with negligible collision probability.

This seems a bit low. Each nonce is 128 bits, and unlike incumbent AES
constructions (i.e. GCM), users aren't dedicating part of it to the
internal counter (thus resulting in a shorter nonce). The safety limit for
AES-GCM is 2^32 because the 96-bit nonce would exceed a 2^-32 collision
probability after 2^32 messages encrypted under a given key.

Unless there's a deeper analysis with how AEGIS-128L uses nonces that I've
missed in the literature, this upper limit would resolve to 2^48 messages,
which can each be up to 2^61 octets in length.

In the Appendix, could you also include a test vector that's expected to
fail? This would signal to implementors that they MUST test the unhappy
path. (This isn't a requirement, by any stretch of the imagination; just a
mechanism that I find useful for specifications.)

Overall, AEGIS looks really interesting.

On Mon, Jan 24, 2022 at 9:46 AM Frank Denis <cfrg=
[email-masked]> wrote:

> Hi,
>
> A new revision of the AEGIS draft has been published:
>
> https://datatracker.ietf.org/doc/draft-denis-aegis-aead/
>
> This version fixes a test vector, emphasizes the importance of not leaking
> any of the decrypted data without tag verification and clarifies how
> finalization is done.
> New implementations of the draft in Go and Python have also been
> contributed.
>
> As usual, feedback would be more than welcome!
>
> Thank you!
>
> -Frank.
>
>
> > On Dec 31, 2021, at 00:54, Frank Denis <cfrg=
> [email-masked]> wrote:
> >
> > Hi everybody,
> >
> > An initial version of a draft documenting the AEGIS AEADs was just
> published:
> >
> > https://www.ietf.org/archive/id/draft-denis-aegis-aead-00.html
> >
> > The original version of AEGIS was published in 2014, then updated for
> the CAESAR competition that it eventually became a finalist of, for
> high-performance applications. Since then, AEGIS variants have consistently
> remained among the fastest performers of the Supercop benchmark.
> >
> > Even on high-end CPUs, there’s a need for faster alternatives to
> AES-GCM. 6G networks were a justification for the ROCCA cipher (based on
> AEGIS) but more broadly, as service providers converge towards encrypting
> all data at-rest and in-transit, the ability to process more data per CPU
> core is extremely useful.
> >
> > AEGIS leverages a large inner state and was designed to maximize usage
> of pipelined implementations of the AES permutation, which allow for the
> parallel computation of several AES rounds.
> >
> > All the AEGIS variants don’t require carry-less multiplications, and are
> very simple to implement efficiently.
> >
> > On Intel, PowerPC and ARM CPUs with AES acceleration, they are more than
> 2x faster than their AES-GCM counterparts.
> >
> > They also have a large nonce size (128 or 256 bits), making them safer
> to use than AES-GCM in non-TLS contexts.
> >
> > AEGIS already found its way into the Linux kernel (for dm-crypt) and
> routers (OVH OTB). Independent implementations in various languages have
> been written. However, no document ensuring the interoperability of these
> implementations was previously published.
> >
> > Would documenting the AEGIS AEADs be something that CFRG members could
> possibly help work on/review?
>
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: Frank Denis <[email-masked]>
Date: Wed, 2 Mar 2022 13:12:36 +0100

Hi Soatok,

And thanks a lot for your feedback!

> On Mar 2, 2022, at 8:10 AM, Soatok Dreamseeker <[email-masked]> wrote:
> 

It absolutely should. This has been fixed, thanks!

> I also observe that the congruent truncation isn't specified for AEGIS-256, only AEGIS-128L.

Good catch, thanks! - Fixed.

> Unless there's a deeper analysis with how AEGIS-128L uses nonces that I've missed in the literature, this upper limit would resolve to 2^48 messages, which can each be up to 2^61 octets in length.

That part of the specification had already been updated to allow for 2^48 messages since the previous revision. There are no known issues to look for besides nonce collisions, so 2&48 is fine and aligns with NIST recommendations.

A new revision of the draft with the above changes is going to be published shortly.

> In the Appendix, could you also include a test vector that's expected to fail? This would signal to implementors that they MUST test the unhappy path. (This isn't a requirement, by any stretch of the imagination; just a mechanism that I find useful for specifications.)

This is a good idea. This should ideally match actual results that implementations may end up with if they overlook some details.
Do you have an idea of such vectors that would be worth adding?

Empty inputs/inputs whose sizes are at exactly block boundary are already tested with vectors 1 and 2. 

> Overall, AEGIS looks really interesting.

Thanks!

-Frank.

---

From: Soatok Dreamseeker <[email-masked]>
Date: Wed, 2 Mar 2022 09:27:09 -0500

Hi Frank,

On Wed, Mar 2, 2022 at 7:12 AM Frank Denis <[email-masked]> wrote:

> This is a good idea. This should ideally match actual results that
> implementations may end up with if they overlook some details.

The most useful test case, in my opinion, is where the nonce and key are
switched for the decrypt path, so the given ciphertext/tag will error. A
trivial "bit flipped in ciphertext and/or authentication tag" vector is
also useful.

Thanks for your work on this specification. I'm looking forward to studying
it further.