Re: [PATCH net-next v2 0/5] Reimplement TCP-AO using crypto library

[Eric Biggers]

On Mon, Apr 27, 2026 at 08:09:05PM +0100, Dmitry Safonov wrote:
> > 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 do like these numbers quite much! Yet, as I mentioned in version 1,
> removing a fallback for other algorithms' support does not sound good
> to me. There are two reasons:
> - Ronald P. Bonica (the original RFC5925 author), together with Tony
> Li do have an active RFC draft to support the additional algorithms
> [1], potentially in addition to TCP Extended Options [2]
> - There is at least one open-source BGP implementation (BIRD) that
> allows using the algorithms that you are removing [3]. Without a
> deprecation period and communication with at least known open source
> users, it implies intentionally breaking them, which I can't agree
> with.
> 
> I don't feel like Naking as we don't have any customers using anything
> other than the 3 algorithms above (and BGP implementation is
> [unfortunately] closed-source, so that would not feel appropriate even
> if we had such customers), yet I do feel like it's worth and
> appropriate to express my thoughts/concerns.
> 
> [1] https://www.ietf.org/archive/id/draft-bonica-tcpm-tcp-ao-algs-00.html
> [2] https://www.ietf.org/archive/id/draft-bonica-tcpm-extended-options-00.html
> [3] https://github.com/CZ-NIC/bird/blob/master/sysdep/linux/sysio.h#L246

I think the usual "it's not really broken if no one notices" is likely
to apply here.  Indeed, there have been many cases where algorithms have
been removed from the crypto API before, despite this theoretically
impacting UAPI.  Just some of the removals from crypto_ahash over the
years that come to mind are the Tiger hash algorithms, multiple variants
of RIPEMD, multiple CRC variants, GHASH, Poly1305, NH, and POLYVAL.

The reality is that the crypto API's algorithm specification language
provides way more "flexibility" than anyone knows what to do with or
ever should have existed at all, let alone been exposed directly to
userspace.

We don't have a lot of choice but to clean up these old mistakes to keep
Linux maintainable going forwards, reduce the chance for user error, and
optimize for the things that actually matter.

And again, as I said, if there is another algorithm that someone
actually needs, we can add it back as a bug fix (or as a new feature,
considering that some never worked in the first place).

- Eric