[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMj1kXEve+1uPcdECLeyD_N-prXvbe7jhOYoNO66S1eaxg-JNg@mail.gmail.com>
Date: Mon, 10 Nov 2025 16:51:36 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.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 Mon, 10 Nov 2025 at 00:49, Eric Biggers <ebiggers@...nel.org> 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
>
Reviewed-by: Ard Biesheuvel <ardb@...nel.org>
Powered by blists - more mailing lists