Re: [PATCH v2] lib/crypto: Add SHA3-224, SHA3-256, SHA3-384, SHA-512, SHAKE128, SHAKE256

[Eric Biggers <ebiggers@kernel.org>]

On Fri, Sep 19, 2025 at 08:48:00PM +0100, David Howells wrote:
> Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > This should be based on libcrypto-next.
> 
> This?
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git libcrypto-next

Yes.

> > and that the functions can be called in any context.
> 
> "Context" as in?

See the "Function context" section of
Documentation/doc-guide/kernel-doc.rst

> > The testing situation looks odd.  This patch adds six KUnit test suites:
> > one for each of the SHA-3 algorithms.  But they only include the
> > hash-test-template.h test cases, and they don't test the unique behavior
> > of SHAKE.  The KUnit tests need to fully test the library.
> 
> Yes, I'm aware of that.  The hash-test-template template is rather rigid

hash-test-template.h is designed for traditional hash functions.  If
you'd like to extend it to support XOFs, that's one option.  But I think
just keeping the XOF testing in sha3_kunit.c would make sense for now.

> and not always correct in its assertions (for instance requiring the
> final function to have zeroed the context - I had to modify my API to
> work around the testsuite).

But that's the correct behavior.  Callers may be hashing sensitize data,
so *_final() zeroizes the context.

The "multiple squeezes" use case should use different functions.

> > I also think that splitting the SHA-3 tests into six KUnit test suites
> > is awkward.  I know I did something similar for SHA-2, but it made more
> > sense for SHA-2 because (1) there are only four SHA-2 variants, (2)
> > SHA-256 and SHA-512 don't share any code, and (3) there wasn't anything
> > more to add on top of hash-test-template.h.  In contrast, SHA-3 has six
> > variants, which all share most of their code, and there will need to be
> > SHA-3 specific tests (for the XOFs).
> 
> Yes, but I believe you wanted me to use hash-test-template.  The problem is
> that it hard-encodes by macroisation of the #include's file various parameters
> including the hash size.

Did you miss my response at
https://lore.kernel.org/linux-crypto/20250917192829.GA8743@quark/ ?

- Eric