Adding SHAKE hash algorithms to SHA-3

Adding SHAKE hash algorithms to SHA-3

[David Howells]

Hi Herbert,

I'm looking at adding ML-DSA from leancrypto to the kernel to support PQC
module signing.  This requires some SHAKE algorithms, however.  Leancrypto
comes with its own SHA-3 implementation that also implements these, but I'd
rather use the already existing kernel one.

The problem is that struct shash_alg expects the digestsize to be fixed - but
with SHAKE this isn't the case.  If it's okay with you, I'll replace the
digestsize field with a set_digestsize and a get_digestsize function as
leancrypto does.

David

Re: Adding SHAKE hash algorithms to SHA-3

[Herbert Xu]

On Mon, Sep 15, 2025 at 09:30:00AM +0100, David Howells wrote:
> Hi Herbert,
> 
> I'm looking at adding ML-DSA from leancrypto to the kernel to support PQC
> module signing.  This requires some SHAKE algorithms, however.  Leancrypto
> comes with its own SHA-3 implementation that also implements these, but I'd
> rather use the already existing kernel one.
> 
> The problem is that struct shash_alg expects the digestsize to be fixed - but
> with SHAKE this isn't the case.  If it's okay with you, I'll replace the
> digestsize field with a set_digestsize and a get_digestsize function as
> leancrypto does.

I presume the algorithm choice is fixed, right? If so you should be
using lib/crypto.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Adding SHAKE hash algorithms to SHA-3

[David Howells]

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> I presume the algorithm choice is fixed, right?

I think so.

> If so you should be using lib/crypto.

Okay.  That will automatically use CPU-optimised versions if available?

Btw, are the algorithms under crypto/ going to be switched to use the
implementations under lib/crypto/?

David

Re: Adding SHAKE hash algorithms to SHA-3

[Eric Biggers]

On Mon, Sep 15, 2025 at 09:48:14PM +0100, David Howells wrote:
> > If so you should be using lib/crypto.
> 
> Okay.  That will automatically use CPU-optimised versions if available?

If it's done properly, yes.  It's already been done for various other
algorithms, such as SHA-1 and SHA-2.  No one has done SHA-3 yet, but we
should.

> Btw, are the algorithms under crypto/ going to be switched to use the
> implementations under lib/crypto/?

Many already have, and most of the remaining ones should be as well.

- Eric

Re: Adding SHAKE hash algorithms to SHA-3

[David Howells]

Herbert Xu <herbert@gondor.apana.org.au> wrote:

> I presume the algorithm choice is fixed, right? If so you should be
> using lib/crypto.

Actually...  Having dug into the dilithium code some more, the answer appears
to be both yes _and_ no.

It's quite complicated, and in some places it uses both SHAKE128 and SHAKE256
fixedly, but I think it can also change the pre-hash between a bunch of
different algorithms, including SHA-512, SHA3-* and SHAKE*.  At least, I think
it can.

David

Re: Adding SHAKE hash algorithms to SHA-3

[Simo Sorce]

On Fri, 2025-09-19 at 07:41 +0100, David Howells wrote:
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
> 
> > I presume the algorithm choice is fixed, right? If so you should be
> > using lib/crypto.
> 
> Actually...  Having dug into the dilithium code some more, the answer appears
> to be both yes _and_ no.
> 
> It's quite complicated, and in some places it uses both SHAKE128 and SHAKE256
> fixedly, but I think it can also change the pre-hash between a bunch of
> different algorithms, including SHA-512, SHA3-* and SHAKE*.  At least, I think
> it can.

We are probably not interested in the HashML-DSA variant, so you should
probably ignore that part of the specification for now.
It is easy to implement on top of Pure ML-DSA if you allow the caller
to specify and externally composed mu.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc

Re: Adding SHAKE hash algorithms to SHA-3

[Stephan Müller]

Am Freitag, 19. September 2025, 15:57:05 Mitteleuropäische Sommerzeit schrieb 
Simo Sorce:

Hi Simo,

> We are probably not interested in the HashML-DSA variant, so you should
> probably ignore that part of the specification for now.
> It is easy to implement on top of Pure ML-DSA if you allow the caller
> to specify and externally composed mu.

The key is to have a dedicated function for the Verify.Internal function which 
is wrapped by the pure/prehash API, for example as done in [1]. This way you 
can first have a pure implementation followed, if necessary, by a prehash API 
without changing the actual algorithm, e.g with [2] and [3] where those two 
would be the actual API to be exported.

The question on external Mu, however, is a bit more tricky: it requires the 
injection of a variable that is used in one processing step of 
Verify.Internal. That variable comes from the caller, but somehow needs to be 
transported to the internal - for example by [4].

[1] https://github.com/smuellerDD/leancrypto/blob/master/ml-dsa/src/
dilithium_signature_impl.h#L888

[2] https://github.com/smuellerDD/leancrypto/blob/master/ml-dsa/src/
dilithium_signature_impl.h#L947

[3] https://github.com/smuellerDD/leancrypto/blob/master/ml-dsa/src/
dilithium_signature_impl.h#L906

[4] https://github.com/smuellerDD/leancrypto/blob/master/ml-dsa/src/
dilithium_signature_impl.h#L784

Ciao
Stephan