Re: [RFC PATCH 0/8] Reimplement TCP-AO using crypto library

[Eric Biggers]

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