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

[Antonio Quartulli <antonio@mandelbit.com>]

On 12/11/2026 17:44, Jason A. Donenfeld wrote:
> On Thu, Nov 12, 2026 at 5:20 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>>> This series adds AEGIS-128X4, the 4-way parallel variant of AEGIS-128L
>>> specified in RFC 10032 (Informational, September 2026), as a crypto
>>> library with an x86_64 VAES-AVX512 implementation, a KUnit test suite
>>> and benchmark, and a crypto API wrapper.
>>>
>>> AEGIS-128X4 runs four AEGIS-128L instances, one per 128-bit lane of a
>>> 512-bit vector, so that each state update is eight VAESENC instructions
>>> on zmm registers.  On CPUs with VAES and AVX-512 it is very fast even for
>>> short messages, which is what makes it attractive for network protocols.
>>>
>>> The intended user is ovpn, the OpenVPN data channel offload driver. In
>>> single-stream ovpn tests over a 100 Gbit/s link, with both ciphers used
>>> through the crypto API, the sending CPU spent 1266 cycles per packet with
>>> AEGIS-128X4 against 1448 with AES-GCM over TCP, and 1032 against 1122
>>> with UDP GSO input. It is posted as an RFC because ovpn can't use it
>>> yet.
>>>
>>
>> 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?

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

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.




Regards,


-- 
Antonio Quartulli

CEO and Co-Founder
Mandelbit Srl
https://www.mandelbit.com