Hi Eric,

On Sat, 7 Mar 2026 at 22:46, Eric Biggers [off-list ref] wrote:
[..]

This series refactors the TCP-AO (TCP Authentication Option) code to do
MAC and KDF computations using lib/crypto/ instead of crypto_ahash.
This greatly simplifies the code and makes it much more efficient.  The
entire tcp_sigpool and crypto_ahash cloning mechanisms become
unnecessary and are removed, as the problems they were designed to solve
don't exist with the library APIs.

To make this possible, this series also restricts the supported
algorithms to a reasonable set, rather than supporting arbitrary
algorithms that don't make sense and are very likely not being used.
Specifically, this series leaves in place the support for AES-128-CMAC
and HMAC-SHA1 which are the only algorithms that actually have an RFC
specifying their use in TCP-AO, along with HMAC-SHA256 which is a
reasonable algorithm to continue supporting as a Linux extension.

This passes the tcp_ao selftests (tools/testing/selftests/net/tcp_ao).

To get a sense for how much more efficient this makes the TCP-AO code,
here's a microbenchmark for tcp_ao_hash_skb() with skb->len == 128:

        Algorithm       Avg cycles (before)     Avg cycles (after)
        ---------       -------------------     ------------------
        HMAC-SHA1       3319                    1256
        HMAC-SHA256     3311                    1344
        AES-128-CMAC    2720                    1107

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 - that's why I originally
intentionally gave a user options to use not only mandatory
algorithms. Well, that's sentimental, and yet I see that other BGP
implementations already allow these optional algorithms.

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

Thanks,
             Dmitry