From: "Ard Biesheuvel" <ardb@kernel.org>
To: "Eric Biggers" <ebiggers@kernel.org>, netdev@vger.kernel.org
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
"Eric Dumazet" <edumazet@google.com>,
"Neal Cardwell" <ncardwell@google.com>,
"Kuniyuki Iwashima" <kuniyu@google.com>,
"David S . Miller" <davem@davemloft.net>,
"David Ahern" <dsahern@kernel.org>,
"Jakub Kicinski" <kuba@kernel.org>,
"Paolo Abeni" <pabeni@redhat.com>,
"Simon Horman" <horms@kernel.org>,
"Jason A . Donenfeld" <Jason@zx2c4.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"Dmitry Safonov" <0x7f454c46@gmail.com>
Subject: Re: [RFC PATCH 0/8] Reimplement TCP-AO using crypto library
Date: Mon, 09 Mar 2026 09:17:36 +0100 [thread overview]
Message-ID: <5ed0c7d9-07e7-4011-a3a5-32d1e2b06e3f@app.fastmail.com> (raw)
In-Reply-To: <20260307224341.5644-1-ebiggers@kernel.org>
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?
next prev parent reply other threads:[~2026-03-09 8:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-07 22:43 Eric Biggers
2026-03-07 22:43 ` [RFC PATCH 1/8] net/tcp-ao: Drop support for most non-RFC-specified algorithms Eric Biggers
2026-03-07 22:43 ` [RFC PATCH 2/8] net/tcp-ao: Use crypto library API instead of crypto_ahash Eric Biggers
2026-03-07 22:43 ` [RFC PATCH 3/8] net/tcp-ao: Use stack-allocated MAC and traffic_key buffers Eric Biggers
2026-03-07 22:43 ` [RFC PATCH 4/8] net/tcp-ao: Return void from functions that can no longer fail Eric Biggers
2026-03-07 22:43 ` [RFC PATCH 5/8] net/tcp: Remove tcp_sigpool Eric Biggers
2026-03-07 22:43 ` [RFC PATCH 6/8] crypto: hash - Remove support for cloning hash tfms Eric Biggers
2026-03-07 22:43 ` [RFC PATCH 7/8] crypto: cipher - Remove support for cloning cipher tfms Eric Biggers
2026-03-07 22:43 ` [RFC PATCH 8/8] crypto: api - Remove core support for cloning tfms Eric Biggers
2026-03-09 8:17 ` Ard Biesheuvel [this message]
2026-03-09 22:33 ` [RFC PATCH 0/8] Reimplement TCP-AO using crypto library Dmitry Safonov
2026-03-09 23:30 ` Eric Biggers
2026-03-10 7:42 ` Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5ed0c7d9-07e7-4011-a3a5-32d1e2b06e3f@app.fastmail.com \
--to=ardb@kernel.org \
--cc=0x7f454c46@gmail.com \
--cc=Jason@zx2c4.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=ebiggers@kernel.org \
--cc=edumazet@google.com \
--cc=herbert@gondor.apana.org.au \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=kuniyu@google.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ncardwell@google.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®