linux-kernel - Re: [PATCH v3 7/8] crypto/sha3: Add SHAKE128/256 support

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: <20251001152528.GA1592@sol>
Date: Wed, 1 Oct 2025 08:25:28 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: "Jason A . Donenfeld" <Jason@...c4.com>,
	Ard Biesheuvel <ardb@...nel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Stephan Mueller <smueller@...onox.de>, linux-crypto@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 7/8] crypto/sha3: Add SHAKE128/256 support

On Wed, Oct 01, 2025 at 02:02:26PM +0100, David Howells wrote:
> Eric Biggers <ebiggers@...nel.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