Re: [RFC PATCH 0/5] lib/crypto: Add AEGIS-128X4

[Eric Biggers <ebiggers@kernel.org>]

On Thu, Nov 12, 2026 at 11:54:05PM +0100, Antonio Quartulli wrote:
> > > We used to have implementations of aegis128l and aegis256 in the kernel as
> > > well (along with morus), but we removed them on the basis that it was
> > > aegis128 that won the competition.
> > > 
> > > As far as I know, nobody actually uses any of that code, though, so I am
> > > quite to surprised to see now that it was aegis128 that was dropped
> > > from the portfolio, and aegis128l and aegis256 have made a miraculous
> > > return, along with some other variants that appear to be tied to the
> > > register width. What happens when 8-way vector registers become
> > > commonplace? Create yet another aegis variant that case use them
> > > efficiently?
> > > 
> > > So I'm struggling to see why we should take this RFC seriously, to be
> > > honest ...
> > 
> > I'm also not really sure what's going on. CAESAR competition selected
> > aegis128 and listed 128l and 256 as "additional finalists". And then
> > RFC10032 has written up 128L, 256, 128X, 256X, but not the original
> > 128 that was selected. And then none of this has been picked up by
> > NIST. Meanwhile, NIST's light weight crypto competition selected
> > ASCON, which as the "lightweight" as opposed to "high performance"
> > pick in CAESAR. So I dunno! I've been waiting for the dust to settle
> > for a little bit.
> 
> To be honest I did not try to figure out what was going on, but for sure
> there was "some confusion".
> 
> By looking at RFC10032 and its references, it seems that various studies
> were conducted on AEGIS128 after it won CAESAR and they highlighted some
> deficiencies. I am assuming that this is why it was decided to skip it
> during the standardization process and focus on its stronger siblings.
> 
> This said, our decision to work on AEGIS128X4 came from the fact that it was
> expected to be faster than AES-GCM (current default for ovpn), especially
> when working on chunks larger than a standard packet (i.e. TSO/GSO/GRO
> case).
> 
> With RFC10032 standardizing it (and its siblings), we thought this would be
> the beginning of the AEGIS era, with more use cases popping up.
> 
> RFC10032 was published last September - why wouldn't you take this seriously
> at this point?

The kernel previously carried 5 AEGIS and MORUS algorithms, and that was
a mistake.  We ended up having to maintain all of them, with heavily
duplicated code (and often buggy, generating syzbot reports).
Eventually we were able to drop 4 -- after 2 were even cryptographically
broken.  Now it seems even the last 1 was a mistake too.

Now we have RFC 10032, which specifies an unbounded number of
incompatible AEAD algorithms in four families.  It leaves the degree of
parallelism "D" unspecified, with only a few examples given in the
"Operational Considerations" section -- not the actual specification.

> I am not the one writing ciphers and judging them during competitions,
> therefore I think the 8-way question should not be for me :-)

I'm afraid it is for you, as you're the one proposing that the kernel
carry this particular variant.  This proposal does not seem to consider
any of the other incompatible variants specified in RFC 10032, including
256-bit key variants which are generally preferred these days.  It also
still has the flaw of a fixed degree of parallelism.  Finally, it also
ignores the kernel's existing legacy AEGIS-128 code, which we still have
to support too, and doesn't attempt to share any code with it.

Fragmentation is a huge problem, especially when code cannot be shared
and each algorithm has to be optimized for each architecture.

> As a side note, our tests on a prototype ovpn using AEGIS128X4 confirmed
> higher throughput, therefore we were hoping to have a chance to see it
> merged.

Anyway, we do not support things just because they have an RFC.  There
has to be a technical reason.

Being faster than AES-GCM is indeed a technical reason, so there is
still a chance this could be worth doing.

It's just not very convincing when AES-GCM is already so fast.  It got
3-4x faster on x86_64 in the last few years, due to the VAES
instructions and the code I wrote to use them, and of course AES-GCM's
natural parallelism (there's no need for "AES-GCMX4").

Moreover, from the benchmark numbers you gave, it seems most of the
remaining overhead is not in the crypto algorithm itself anyway.

So perhaps it's best to focus optimizations elsewhere in the networking
stack for now, maybe work on switching from crypto_aead to lib/crypto/
to eliminate the known-problematic crypto_aead overhead too, and wait
for the dust to settle on AEGIS a bit?

If we are going to support this, we would at least need to know that it
is actually worthwhile and will be "the one", rather than the first of
many variants springing up with duplicated code.

- Eric