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

[Ard Biesheuvel]

On Tue, 10 Mar 2026, at 00:30, Eric Biggers wrote:
> 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.
>

Agree that supporting arbitrary algorithms is a bug, not a feature, and if anyone does notice that a combination that actually makes /some/ sense no longer works, we can always add it back in library form (even though generating a 64-byte SHA-512 digest and truncating it to 20 bytes seems kind of pointless). But supporting CRC-32 or HMAC-MD5 is just ridiculous so let's not go there.