From: Eric Biggers <ebiggers@kernel.org>
To: Joachim Vandersmissen <git@jvdsn.com>
Cc: dhowells@redhat.com, linux-crypto@vger.kernel.org
Subject: Re: SHAKE256 support
Date: Wed, 17 Sep 2025 23:17:02 -0500 [thread overview]
Message-ID: <20250918041702.GA12019@quark> (raw)
In-Reply-To: <783702f5-4128-4299-996b-fe95efb49a4b@jvdsn.com>
On Wed, Sep 17, 2025 at 10:53:12PM -0500, Joachim Vandersmissen wrote:
> Hi Eric, David,
>
> On 9/17/25 1:48 PM, Eric Biggers wrote:
> > On Wed, Sep 17, 2025 at 05:20:43PM +0100, David Howells wrote:
> >
> > > 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.
> I'm not too familiar with the history of lib/crypto/, but I have noticed
> over the past months that there has been a noticeable shift to moving
> in-kernel users from the kernel crypto API to the library APIs. While this
> seems to be an overall improvement, it does make FIPS compliance more
> challenging. If the kernel crypto API is the only user of lib/crypto/, it is
> possible to make an argument that the testmgr.c self-tests cover the
> lib/crypto/ implementations (since those would be called at some point).
> However since other code is now calling lib/crypto/ directly, that
> assumption may no longer hold.
> >
> > *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.
>
> Currently I don't see how direct users of the lib/crypto/ APIs can be FIPS
> compliant; self-tests are only one of the requirements that are not
> implemented. It would be one of the more straightforward requirements to
> implement though, if this is something the kernel project would accept at
> that (lib/crypto/) layer.
If you find that something specific you need is missing, then send a
patch, with a real justification. Vague concerns about unspecified
"requirements" aren't very helpful.
- Eric
next prev parent reply other threads:[~2025-09-18 4:17 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
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 [this message]
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=20250918041702.GA12019@quark \
--to=ebiggers@kernel.org \
--cc=dhowells@redhat.com \
--cc=git@jvdsn.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.