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

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: <20250919203208.GA8350@quark>
Date: Fri, 19 Sep 2025 15:32:08 -0500
From: Eric Biggers <ebiggers@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>,
	Ard Biesheuvel <ardb@...nel.org>,
	Harald Freudenberger <freude@...ux.ibm.com>,
	Holger Dengler <dengler@...ux.ibm.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Stephan Mueller <smueller@...onox.de>, Simo Sorce <simo@...hat.com>,
	linux-crypto@...r.kernel.org, linux-s390@...r.kernel.org,
	keyrings@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] lib/crypto: Add SHA3-224, SHA3-256, SHA3-384,
 SHA-512, SHAKE128, SHAKE256

On Fri, Sep 19, 2025 at 08:48:00PM +0100, David Howells wrote:
> Eric Biggers <ebiggers@...nel.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