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

 crypto/ahash.c                                |  70 --
 crypto/api.c                                  |  26 -
 crypto/cipher.c                               |  28 -
 crypto/cmac.c                                 |  16 -
 crypto/cryptd.c                               |  16 -
 crypto/hmac.c                                 |  31 -
 crypto/internal.h                             |   2 -
 crypto/shash.c                                |  37 -
 include/crypto/hash.h                         |   8 -
 include/crypto/internal/cipher.h              |   2 -
 include/net/tcp.h                             |  42 +-
 include/net/tcp_ao.h                          |  69 +-
 net/ipv4/Kconfig                              |   8 +-
 net/ipv4/Makefile                             |   1 -
 net/ipv4/tcp_ao.c                             | 677 +++++++++---------
 net/ipv4/tcp_output.c                         |  10 +-
 net/ipv4/tcp_sigpool.c                        | 366 ----------
 net/ipv6/tcp_ao.c                             | 139 ++--
 tools/testing/selftests/net/tcp_ao/config     |   3 -
 .../selftests/net/tcp_ao/key-management.c     |  41 +-
 20 files changed, 435 insertions(+), 1157 deletions(-)
 delete mode 100644 net/ipv4/tcp_sigpool.c


base-commit: 0a217be68aedd0f6b48cf0476462bc94bd73eee7
-- 
2.53.0

Hi Eric,

On Sat, 7 Mar 2026 at 22:46, Eric Biggers <ebiggers@kernel.org> 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

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

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.

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@kernel.org>

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?