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

[Ard Biesheuvel]

On Sat, 7 Mar 2026, at 23:43, Eric Biggers wrote:
> This series can also be retrieved from:
>
>     git fetch 
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git 
> tcp-ao-v1
>
> For now this series is an RFC, since it depends on the AES-CMAC library
> API that is queued in libcrypto-next for 7.1.  So, the soonest that this
> could be applied to net-next is 7.2.  I'm sending it out now in case
> anyone has any early feedback.
>
> 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
>
> Eric Biggers (8):
>   net/tcp-ao: Drop support for most non-RFC-specified algorithms
>   net/tcp-ao: Use crypto library API instead of crypto_ahash
>   net/tcp-ao: Use stack-allocated MAC and traffic_key buffers
>   net/tcp-ao: Return void from functions that can no longer fail
>   net/tcp: Remove tcp_sigpool
>   crypto: hash - Remove support for cloning hash tfms
>   crypto: cipher - Remove support for cloning cipher tfms
>   crypto: api - Remove core support for cloning tfms
>

Reviewed-by: Ard Biesheuvel <ardb@xxxxxxxxxx>

I wonder how widely this is being used, given that there are much cheaper options than CMAC or HMAC, and nobody bothered to ratify the HMAC-SHA256 draft.

Anybody have any insights?