All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: David Howells <dhowells@redhat.com>
Cc: linux-crypto@vger.kernel.org
Subject: Re: SHAKE256 support
Date: Wed, 17 Sep 2025 13:48:56 -0500	[thread overview]
Message-ID: <20250917184856.GA2560@quark> (raw)
In-Reply-To: <3226361.1758126043@warthog.procyon.org.uk>

On Wed, Sep 17, 2025 at 05:20:43PM +0100, David Howells wrote:
> Okay, I have lib/crypto/sha3 working.  One question though: why are the hash
> tests built as separate kunit modules rather than being built into the
> algorithm module init function and marked __init/__initdata?

KUnit is the standard way to do unit testing in the kernel these days.
The kernel community has been working on migrating legacy ad-hoc tests
over to KUnit.  This is not specific to lib/crypto/.

> For FIPS compliance, IIRC, you *have* to run tests on the algorithms,
> so wouldn't using kunit just be a waste of resources?

The lib/crypto/ KUnit tests are real tests, which thoroughly test each
algorithm.  This includes computing thousands of hashes for each hash
algorithm, for example.

FIPS pre-operational self-testing, if and when it is required, would be
a completely different thing.  For example, FIPS often requires only a
single test (with a single call to the algorithm) per algorithm.  Refer
to section 10.3.A of "Implementation Guidance for FIPS 140-3 and the
Cryptographic Module Validation Program"
(https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf)

Of course, so far the people doing FIPS certification of the whole
kernel haven't actually cared about FIPS pre-operational self-tests for
the library functions.  lib/ has had SHA-1 support since 2005, for
example, and it's never had a FIPS pre-operational self-test.

*If* that's changing and the people doing FIPS certifications of the
whole kernel have decided that the library functions actually need FIPS
pre-operational self-tests after all, that's fine.  But please don't try
to misuse the actual (KUnit) tests.  Instead, just add exactly what is
actually required by the FIPS to the appropriate subsys_initcall in the
library.  For SHA-3 for example, you'd only need to compute and verify a
single hash, using any of SHA3-224, SHA3-256, SHA3-384, SHA3-512.  Then
panic() if it fails and fips_enabled is true.

- Eric

  reply	other threads:[~2025-09-17 18:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-15 20:51 SHAKE256 support David Howells
2025-09-15 21:00 ` David Howells
2025-09-15 22:07   ` Eric Biggers
2025-09-17 16:20     ` David Howells
2025-09-17 18:48       ` Eric Biggers [this message]
2025-09-17 19:11         ` David Howells
2025-09-17 19:28           ` Eric Biggers
2025-09-18  3:53         ` Joachim Vandersmissen
2025-09-18  4:17           ` Eric Biggers
2025-09-18 13:37             ` Simo Sorce
2025-09-18 15:53               ` Eric Biggers
2025-09-19  0:05           ` Theodore Ts'o

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250917184856.GA2560@quark \
    --to=ebiggers@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=linux-crypto@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.