[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251111192815.GA1748@sol>
Date: Tue, 11 Nov 2025 11:28:15 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: linux-crypto@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>,
"Jason A . Donenfeld" <Jason@...c4.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
linux-arm-kernel@...ts.infradead.org, x86@...nel.org
Subject: Re: [PATCH 0/9] POLYVAL library
On Sun, Nov 09, 2025 at 03:47:15PM -0800, Eric Biggers wrote:
> This series is targeting libcrypto-next. It can also be retrieved from:
>
> git fetch https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git polyval-lib-v1
>
> This series migrates the POLYVAL code to lib/crypto/. It turns out that
> just like Poly1305, the library is a much better fit for it.
>
> This series also replaces the generic implementation of POLYVAL with a
> much better one.
>
> Notably, this series improves the performance of HCTR2, since it
> eliminates unnecessary overhead that was being incurred by accessing
> POLYVAL via the crypto_shash API. I see a 45% increase in throughput
> with 64-byte messages, 53% with 128-byte, or 6% with 4096-byte.
>
> It also eliminates the need to explicitly enable the optimized POLYVAL
> code, as it's now enabled automatically when HCTR2 support is enabled.
>
> Eric Biggers (9):
> crypto: polyval - Rename conflicting functions
> lib/crypto: polyval: Add POLYVAL library
> lib/crypto: tests: Add KUnit tests for POLYVAL
> lib/crypto: arm64/polyval: Migrate optimized code into library
> lib/crypto: x86/polyval: Migrate optimized code into library
> crypto: hctr2 - Convert to use POLYVAL library
> crypto: polyval - Remove the polyval crypto_shash
> crypto: testmgr - Remove polyval tests
> fscrypt: Drop obsolete recommendation to enable optimized POLYVAL
>
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-next
- Eric
Powered by blists - more mailing lists