lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXE1mhu7u5RwhCBA_RUGV6JSDV-GQPpq+thE-0-oVxrmfw@mail.gmail.com>
Date: Mon, 10 Nov 2025 16:21:39 +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 2/9] lib/crypto: polyval: Add POLYVAL library

Hi,

On Mon, 10 Nov 2025 at 00:49, Eric Biggers <ebiggers@...nel.org> wrote:
>
> Add support for POLYVAL to lib/crypto/.
>
> This will replace the polyval crypto_shash algorithm and its use in the
> hctr2 template, simplifying the code and reducing overhead.
>
> Specifically, this commit introduces the POLYVAL library API and a
> generic implementation of it.  Later commits will migrate the existing
> architecture-optimized implementations of POLYVAL into lib/crypto/ and
> add a KUnit test suite.
>
> I've also rewritten the generic implementation completely, using a more
> modern approach instead of the traditional table-based approach.  It's
> now constant-time, requires no precomputation or dynamic memory
> allocations, decreases the per-key memory usage from 4096 bytes to 16
> bytes, and is faster than the old polyval-generic even on bulk data
> reusing the same key (at least on x86_64, where I measured 15% faster).
> We should do this for GHASH too, but for now just do it for POLYVAL.
>

Very nice.

GHASH might suffer on 32-bit, I suppose, but taking this approach at
least on 64-bit also for GHASH would be a huge improvement.

I had a stab at replacing the int128 arithmetic with
__builtin_bitreverse64(), but it seems to make little difference (and
GCC does not support it [yet]). I've tried both arm64 and x86, and the
perf delta (using your kunit benchmark) is negligible in either case.
(FYI)



> Signed-off-by: Eric Biggers <ebiggers@...nel.org>
> ---
>  include/crypto/polyval.h | 171 +++++++++++++++++++++-
>  lib/crypto/Kconfig       |  10 ++
>  lib/crypto/Makefile      |   8 +
>  lib/crypto/polyval.c     | 307 +++++++++++++++++++++++++++++++++++++++
>  4 files changed, 493 insertions(+), 3 deletions(-)
>  create mode 100644 lib/crypto/polyval.c
>

Reviewed-by: Ard Biesheuvel <ardb@...nel.org>
Tested-by: Ard Biesheuvel <ardb@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ