From: Eric Biggers <ebiggers@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: linux-crypto@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
"Jason A . Donenfeld" <Jason@zx2c4.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH 16/17] crypto: jitterentropy - use default sha3 implementation
Date: Mon, 20 Oct 2025 21:20:57 +0000 [thread overview]
Message-ID: <20251020212057.GA83624@google.com> (raw)
In-Reply-To: <1062228.1760956530@warthog.procyon.org.uk>
On Mon, Oct 20, 2025 at 11:35:30AM +0100, David Howells wrote:
> Why don't you take my approach and just call lib/crypto/sha3 directly rather
> than using a crypto/ object as an intermediary if that crypto/ object is just
> going to wrap lib/crypto?
We'll do that, and thanks for writing the patch already! But that's
something to do in a later patch after adding the library API. Your
patch description kind of raised a red flag:
Make the jitterentropy RNG use lib/crypto/sha3 rather than
crypto/sha3.
For some reason it goes absolutely wild if crypto/sha3 is
reimplemented to use lib/crypto/sha3, but it's fine if it uses lib
directly.
That implies that your changes broke crypto_shash, so you *had* to
convert to the library right away as a workaround for that.
That shouldn't be necessary. We should generally keep crypto_shash
working for now. In which case, all jitterentropy should need for now
is a simple substitution s/sha3-256-generic/sha3-256/.
We'll convert jitterentropy to use the library API too. It's better,
after all. But it should be done later and because the library API is
better -- not as some sort of workaround.
- Eric
next prev parent reply other threads:[~2025-10-20 21:21 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-20 0:50 [PATCH 00/17] SHA-3 library Eric Biggers
2025-10-20 0:50 ` [PATCH 01/17] s390/sha3: Rename conflicting functions Eric Biggers
2025-10-20 0:50 ` [PATCH 02/17] arm64/sha3: " Eric Biggers
2025-10-20 0:50 ` [PATCH 03/17] lib/crypto: Add SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256 Eric Biggers
2025-10-20 7:07 ` Bagas Sanjaya
2025-10-20 10:39 ` David Howells
2025-10-20 23:54 ` Bagas Sanjaya
2025-10-20 0:50 ` [PATCH 04/17] lib/crypto: Move the SHA3 Iota transform into the single round function Eric Biggers
2025-10-20 0:50 ` [PATCH 05/17] lib/crypto: Add SHA3 kunit tests Eric Biggers
2025-10-20 0:50 ` [PATCH 06/17] lib/crypto: sha3: Fix libsha3 build condition Eric Biggers
2025-10-20 0:50 ` [PATCH 07/17] lib/crypto: sha3: Use appropriate conversions in sha3_keccakf_generic() Eric Biggers
2025-10-20 0:50 ` [PATCH 08/17] lib/crypto: sha3: Drop unfinished SHAKE support from gen-hash-testvecs.py Eric Biggers
2025-10-20 0:50 ` [PATCH 09/17] lib/crypto: sha3: Consistently use EXPORT_SYMBOL_GPL Eric Biggers
2025-10-20 0:50 ` [PATCH 10/17] lib/crypto: sha3: Replace redundant ad-hoc test with FIPS test Eric Biggers
2025-10-20 0:50 ` [PATCH 11/17] lib/crypto: sha3: Simplify the API Eric Biggers
2025-10-20 10:33 ` David Howells
2025-10-20 17:18 ` Eric Biggers
2025-10-20 0:50 ` [PATCH 12/17] lib/crypto: sha3: Document one-shot functions in header and improve docs Eric Biggers
2025-10-20 0:50 ` [PATCH 13/17] crypto: arm64/sha3 - Update sha3_ce_transform() to prepare for library Eric Biggers
2025-10-20 0:50 ` [PATCH 14/17] lib/crypto: arm64/sha3: Migrate optimized code into library Eric Biggers
2025-10-20 0:50 ` [PATCH 15/17] lib/crypto: s390/sha3: " Eric Biggers
2025-10-20 14:00 ` Holger Dengler
2025-10-20 14:23 ` Holger Dengler
2025-10-20 17:57 ` Eric Biggers
2025-10-21 7:24 ` Holger Dengler
2025-10-21 8:43 ` Holger Dengler
2025-10-21 15:49 ` Eric Biggers
2025-10-24 14:24 ` Harald Freudenberger
2025-10-24 16:11 ` Eric Biggers
2025-10-20 0:50 ` [PATCH 16/17] crypto: jitterentropy - use default sha3 implementation Eric Biggers
2025-10-20 10:35 ` David Howells
2025-10-20 21:20 ` Eric Biggers [this message]
2025-10-20 0:50 ` [PATCH 17/17] crypto: sha3 - Reimplement using library API Eric Biggers
2025-10-20 2:45 ` kernel test robot
2025-10-20 5:46 ` kernel test robot
2025-10-21 6:53 ` David Howells
2025-10-22 10:13 ` [PATCH 00/17] SHA-3 library 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=20251020212057.GA83624@google.com \
--to=ebiggers@kernel.org \
--cc=Jason@zx2c4.com \
--cc=ardb@kernel.org \
--cc=dhowells@redhat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.