On Mon, Mar 09, 2026 at 10:33:32PM +0000, Dmitry Safonov wrote:

I like the numbers that you achieved here and tcp_sigpool riddance.
If you want to measure the throughput difference, there are iperf
hacks I made at the time of upstreaming TCP-AO:
https://github.com/0x7f454c46/iperf/tree/tcp-md5-ao

We certainly have to support AES-128-CMAC, HMAC-SHA1 and HMAC-SHA2.
For the last one, we specifically had an RFE from a customer.

It's a little pity to go from ">> Additional algorithms, beyond those
mandated for TCP-AO, MAY be supported." back to "The
mandatory-to-implement MAC algorithms for use with TCP-AO are
described in a separate RFC [RFC5926]." as I've always enjoyed Linux
(and opensource in general) that provides more flexibility than just
strict mandatory required options

I.e.:
"Of course, TCP-AO key contains a shared secret key. It is specified
by the option secret as a text string or as a sequence of hexadecimal
digit pairs (bytestring).
Used cryptographic algorithm can be specified for each key with the
option algorithm. Possible values are: hmac md5, hmac sha1, hmac
sha224, hmac sha256, hmac sha384, hmac sha512, and cmac aes128.
Default value is hmac sha1." [1][2]

I guess that may cause a regression for an existing config.
So, I don't know, could we get your big speedup and yet let the user
choose what algorithm they want to use? Basically, making
tcp_ao_hash_skb() a callback with optional algorithms implementation
and a faster mandatory algorithms that will use
hmac_sha1_init_usingrawkey(), hmac_sha256_init_usingrawkey(),
aes_cmac_preparekey()?

[1] https://bird.nic.cz/doc/bird-3.2.0.html
[2] https://github.com/CZ-NIC/bird/blob/0ee9f93bd076c5cc425ceaec9acedbbb7c9021ec/sysdep/linux/sysio.h#L246

This series already preserves the nonstandard but reasonable HMAC-SHA256
support as a Linux extension.  And users retain a choice of algorithms.
Maybe think of it as helping them make that choice by dropping things
that we know (but the user may not know) should not be chosen.

I mean, even CRC-32 was an option for the MAC.  Really?  That's
something that should be a CVE, not a "feature that demonstrates the
flexibility of open source software".

Offering all four variants of HMAC-SHA2 is also almost entirely
pointless here, given that TCP-AO MACs are limited to 20 bytes by the
TCP options space anyway.

If there are specific additional algorithm(s) that are actually needed
for backwards compatibility, then we can add them to the list of
algorithms that the new implementation supports.  However, do you
actually know of any user using anything other than HMAC-SHA1,
HMAC-SHA256, or AES-128-CMAC?  If so, what is their use case?

But let's not keep the crypto_ahash based implementation of TCP-AO
around as well, as there's a massive amount of complexity and
inefficiency in it.  I think this series makes that very clear.

- Eric