SHAKE128/256 'digest' algos need to be available for the ML-DSA pre-digest,
which is a selectable algorithm and need to be available through the same
API as, say, SHA3-512 and SHA512 both.  Resqueezability (probably) isn't
required for this and they'll produce the default number of bytes as the
digest size.

Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Biggers <ebiggers@kernel.org>
cc: Jason A. Donenfeld <Jason@zx2c4.com>
cc: Ard Biesheuvel <ardb@kernel.org>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: Stephan Mueller <smueller@chronox.de>
cc: linux-crypto@vger.kernel.org
---
 crypto/sha3_generic.c | 26 ++++++++++++++++++++++++++
 1 file changed, 26 insertions(+)

diff --git a/crypto/sha3_generic.c b/crypto/sha3_generic.c
index 6917a1aeb8e5..4fae066ec3f5 100644
--- a/crypto/sha3_generic.c
+++ b/crypto/sha3_generic.c
@@ -95,6 +95,28 @@ static struct shash_alg algs[] = { {
 	.base.cra_flags		= CRYPTO_AHASH_ALG_BLOCK_ONLY,
 	.base.cra_blocksize	= SHA3_512_BLOCK_SIZE,
 	.base.cra_module	= THIS_MODULE,
+}, {
+	.digestsize		= SHAKE128_DEFAULT_SIZE,
+	.init			= crypto_sha3_init,
+	.update			= crypto_sha3_update,
+	.finup			= crypto_sha3_finup,
+	.descsize		= sizeof(struct sha3_ctx),
+	.base.cra_name		= "shake128",
+	.base.cra_driver_name	= "shake128-generic",
+	.base.cra_flags		= CRYPTO_AHASH_ALG_BLOCK_ONLY,
+	.base.cra_blocksize	= SHAKE128_BLOCK_SIZE,
+	.base.cra_module	= THIS_MODULE,
+}, {
+	.digestsize		= SHAKE256_DEFAULT_SIZE,
+	.init			= crypto_sha3_init,
+	.update			= crypto_sha3_update,
+	.finup			= crypto_sha3_finup,
+	.descsize		= sizeof(struct sha3_ctx),
+	.base.cra_name		= "shake256",
+	.base.cra_driver_name	= "shake256-generic",
+	.base.cra_flags		= CRYPTO_AHASH_ALG_BLOCK_ONLY,
+	.base.cra_blocksize	= SHAKE256_BLOCK_SIZE,
+	.base.cra_module	= THIS_MODULE,
 } };
 
 static int __init sha3_generic_mod_init(void)
@@ -121,3 +143,7 @@ MODULE_ALIAS_CRYPTO("sha3-384");
 MODULE_ALIAS_CRYPTO("sha3-384-generic");
 MODULE_ALIAS_CRYPTO("sha3-512");
 MODULE_ALIAS_CRYPTO("sha3-512-generic");
+MODULE_ALIAS_CRYPTO("shake128");
+MODULE_ALIAS_CRYPTO("shake128-generic");
+MODULE_ALIAS_CRYPTO("shake256");
+MODULE_ALIAS_CRYPTO("shake256-generic");

On Fri, Sep 26, 2025 at 03:19:50PM +0100, David Howells wrote:
> SHAKE128/256 'digest' algos need to be available for the ML-DSA pre-digest,
> which is a selectable algorithm and need to be available through the same
> API as, say, SHA3-512 and SHA512 both.  Resqueezability (probably) isn't
> required for this and they'll produce the default number of bytes as the
> digest size.
> 
> Signed-off-by: David Howells <dhowells@redhat.com>
> cc: Eric Biggers <ebiggers@kernel.org>
> cc: Jason A. Donenfeld <Jason@zx2c4.com>
> cc: Ard Biesheuvel <ardb@kernel.org>
> cc: Herbert Xu <herbert@gondor.apana.org.au>
> cc: Stephan Mueller <smueller@chronox.de>
> cc: linux-crypto@vger.kernel.org
> ---
>  crypto/sha3_generic.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)

I recommend holding off on this part until you have a try at using the
SHAKE library API directly.  The dispatch to different algorithms could
be done in the calling code.  This patch would also limit the ML-DSA
code to fixed-size SHAKE outputs; is that really going to be enough?

- Eric

Eric Biggers <ebiggers@kernel.org> wrote:

> I recommend holding off on this part until you have a try at using the
> SHAKE library API directly.  The dispatch to different algorithms could
> be done in the calling code.  This patch would also limit the ML-DSA
> code to fixed-size SHAKE outputs; is that really going to be enough?

Actually, ML-DSA also allows SHA2 hashes for the prehash, so if I use
crypto_shash for that, then I maintain the flexibility through that.

> When there's only a small number of supported algorithms, just doing the
> dispatch in the calling code tends to be simpler than using
> crypto_shash.  For example, see the recent conversion of fs/verity/ to
> use the SHA-2 library API instead of crypto_shash.

That's reinventing the wheel.  Why have crypto_shash at all if we're going to
encourage people to ignore that and use a union and an enum/ops table.

Is the goal to get rid of crypto/ entirely and use lib/crypto/ instead?  Not
that I wouldn't mind a better crypto offloading API - the one we have kind of
sucks, especially for offloading to async crypto h/w (sorry Herbert;-)).

David

On Wed, Oct 01, 2025 at 02:02:26PM +0100, David Howells wrote:
> Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > I recommend holding off on this part until you have a try at using the
> > SHAKE library API directly.  The dispatch to different algorithms could
> > be done in the calling code.  This patch would also limit the ML-DSA
> > code to fixed-size SHAKE outputs; is that really going to be enough?
> 
> Actually, ML-DSA also allows SHA2 hashes for the prehash, so if I use
> crypto_shash for that, then I maintain the flexibility through that.
> 
> > When there's only a small number of supported algorithms, just doing the
> > dispatch in the calling code tends to be simpler than using
> > crypto_shash.  For example, see the recent conversion of fs/verity/ to
> > use the SHA-2 library API instead of crypto_shash.
> 
> That's reinventing the wheel.

Not really.  As I said, in fs/verity/ it was simpler to use the library
APIs, even with multiple algorithms.  I got similar results in net/sctp/
too.  The library APIs are also faster, due to eliminating overhead such
as algorithm lookup by name and indirect calls.

With the library it's also much easier to implement things that don't
fit into the existing paradigm well, such as XOFs.  Case in this point:
this patch adds "shake128" and "shake256" to crypto_shash, but only
offers fixed-size digests.  Which kind of defeats the point of SHAKE.

> Why have crypto_shash at all if we're going to
> encourage people to ignore that and use a union and an enum/ops table.

Mainly because some subsystems accept an arbitrary string in "Crypto API
algorithm syntax" from userspace, and they have to continue supporting
that for backwards compatibility.

Anyway, I'm not saying that you *can't* use crypto_shash.  Just the way
you described it, where using crypto_shash is *required* as soon as
there are two possible algorithms, is not correct.  It's an option.

- Eric