SHAKE256 support

SHAKE256 support

[David Howells]

Hi Eric,

I don't suppose you happen to have SHAKE128 and SHAKE256 support lurking up
your sleeve for lib/crypto/sha512.c?

David

Re: SHAKE256 support

[David Howells]

David Howells <dhowells@redhat.com> wrote:

> I don't suppose you happen to have SHAKE128 and SHAKE256 support lurking up
> your sleeve for lib/crypto/sha512.c?

Actually, I assuming that lib/crypto/sha512.c is SHA-3, but I guess it might
actually be SHA-2.  I don't think it actually says in the file.

David

Re: SHAKE256 support

[Eric Biggers]

On Mon, Sep 15, 2025 at 10:00:13PM +0100, David Howells wrote:
> David Howells <dhowells@redhat.com> wrote:
> 
> > I don't suppose you happen to have SHAKE128 and SHAKE256 support lurking up
> > your sleeve for lib/crypto/sha512.c?
> 
> Actually, I assuming that lib/crypto/sha512.c is SHA-3, but I guess it might
> actually be SHA-2.  I don't think it actually says in the file.

lib/crypto/sha512.c contains implementations of SHA-384 and SHA-512,
which are part of SHA-2.  The SHA-3 equivalents are SHA3-384 and
SHA3-512.

We should move the SHA-3 code into lib/crypto/, just as I've done for
SHA-1 and SHA-2.  I just haven't gotten to it yet.  Nor have I
implemented SHAKE support, which would be new.

Contributions appreciated!

- Eric

Re: SHAKE256 support

[David Howells]

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

David

Re: SHAKE256 support

[Eric Biggers]

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

Re: SHAKE256 support

[David Howells]

Eric Biggers <ebiggers@kernel.org> wrote:

> 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/.

How do you test hashes with variable length digests (e.g. SHAKE128/256) using
the hash testing infrastructure in lib/crypto/tests/?

David

Re: SHAKE256 support

[Eric Biggers]

On Wed, Sep 17, 2025 at 08:11:07PM +0100, David Howells wrote:
> Eric Biggers <ebiggers@kernel.org> wrote:
> 
> > 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/.
> 
> How do you test hashes with variable length digests (e.g. SHAKE128/256) using
> the hash testing infrastructure in lib/crypto/tests/?

Same as BLAKE2s
(https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/tree/lib/crypto/tests/blake2s_kunit.c?h=libcrypto-next).
Just choose a fixed output length to use with hash-test-template.h, and
instantiate those test cases.  Then also add additional test cases to
your *_kunit.c file that cover other output lengths.

If you'd like to refactor things so that some of the variable-length
output test logic can be shared between the BLAKE2s and SHAKE tests,
that is a possibility.  But I expect it wouldn't be worthwhile yet.

- Eric

Re: SHAKE256 support

[Joachim Vandersmissen]

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.

Kind regards,
Joachim

> 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
>

Re: SHAKE256 support

[Eric Biggers]

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

Re: SHAKE256 support

[Simo Sorce]

On Wed, 2025-09-17 at 23:17 -0500, Eric Biggers wrote:
> 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,
as you well know writing patches does not come for free.

The questions here are:
- Are you open to accept patches that enforce some behavior that is
only useful for FIPS compliance?
- Are there any constraints you want followed?

Fundamentally people are asking in advance for guidance of what would
be acceptable so that a patch submission wouldn't waste the submitter
time writing it and your maintainer time reviewing it, if there is
guidance that can be taken in account early on.

As you have seen recently in Oracle's submission some changes could be
quite invasive, would you allow similar changes to what you've seen to
that patchset to land directly in lib/crypto functions ?

Simo.

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

Re: SHAKE256 support

[Eric Biggers]

On Thu, Sep 18, 2025 at 09:37:45AM -0400, Simo Sorce wrote:
> On Wed, 2025-09-17 at 23:17 -0500, Eric Biggers wrote:
> > 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,
> as you well know writing patches does not come for free.
> 
> The questions here are:
> - Are you open to accept patches that enforce some behavior that is
> only useful for FIPS compliance?

As I said already: small patches that add pre-operational self-tests
would generally be fine, if they are shown to actually be needed and are
narrowly scoped to what is actually needed.  Is that what you're asking
about?  If not, please be specific about what you're asking about.

> Fundamentally people are asking in advance for guidance of what would
> be acceptable so that a patch submission wouldn't waste the submitter
> time writing it and your maintainer time reviewing it, if there is
> guidance that can be taken in account early on.
> 
> As you have seen recently in Oracle's submission some changes could be
> quite invasive, would you allow similar changes to what you've seen to
> that patchset to land directly in lib/crypto functions ?

That submission is an entirely different topic.  Obviously, a 100+ patch
series that re-architects the kernel is going to be more controversial
in the community than a patch that just adds a bit of logic, such as a
self-test, under 'if (fips_enabled)'.  But that is a different topic,
and it's unrelated to the current approach to FIPS that is (sort of)
supported by the upstream kernel.  If you would like to comment on that
patch series, perhaps you should respond to that thread and not some
unrelated thread?  This thread is supposed to be about SHAKE256 support.

- Eric

Re: SHAKE256 support

[Theodore Ts'o]

On Wed, Sep 17, 2025 at 10:53:12PM -0500, Joachim Vandersmissen wrote:
> 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.

In general, customers who lookng for FIPS compliance need it for some
specific application --- for example, encrypting medical records, or
credit card numbers, or while establishing TLS connections, etc.  In
my experience, customers do *not* require that all use of encryption
in the kernel, or in various userspce applications, must be FIPS
compliance.

So while some in-kernel users are switching to library API's, it might
not matter.  Heck, in some cases the only thing that might matter is
the OpenSSL userspace library.

I'll also note that if you need formal FIPS certification, what the
FIPS labs certify is a specific binary artifact.  If the binary needs
to change --- say, to fix a critcial high-severity CVE security
vulnerability, fixing the security vulnerability might end up breaking
the FIPS certification, requiring payment of more $$$ to the FIPS
certification lab.  Which is a rather unfortunate incentive about
whether or not security vulnerabilities should be fixed.

So I personally consider FIPS certification to be over-priced security
theater.  If it's needed because the customer needs it, and hopefully,
is willing to pay $$$ for it, my advice is to do the minimal needed so
you can get the magic checkbox so you can sell into the government
market or whaever.  FIPS compliance for its own sake is a waste of
time and effort, and in my opinion, the tax should be paid only by the
customers who want the silly thing.

Cheers,

					- Ted