SHAKE256 support
Hi Eric,
I don't suppose you happen to have SHAKE128 and SHAKE256 support lurking up your sleeve for lib/crypto/sha512.c?
David
Quoted 2 lines · David Howells
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
Quoted 7 lines · David Howells
Quoted 2 lines · David Howells
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.cis 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
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
Quoted 3 lines · David Howells
Okay, I have
lib/crypto/sha3working. 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/.
Quoted 2 lines
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
Quoted 8 lines · Eric Biggers
Quoted 3 lines · David Howells
Okay, I have
lib/crypto/sha3working. 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
Quoted 7 lines · David Howells
Quoted 5 lines · Eric Biggers
Quoted 3 lines · David Howells
Okay, I have
lib/crypto/sha3working. 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?
Quoted 6 lines
Quoted 3 lines
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
Hi Eric, David,
Quoted 15 lines · Eric Biggers
Quoted 2 lines · David Howells
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)
Quoted 4 lines
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.
Quoted 4 lines
*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
Quoted 9 lines
But please don't try
to misuse the actual (KUnit) tests. Instead, just add exactly what is actually required by the FIPS to the appropriatesubsys_initcallin 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. Thenpanic()if it fails andfips_enabledis true.- Eric
Quoted 36 lines · Joachim Vandersmissen
Hi Eric, David,
Quoted 15 lines · Eric Biggers
Quoted 2 lines · David Howells
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)Quoted 4 lines
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 oflib/crypto/, it is possible to make an argument that thetestmgr.cself-tests cover thelib/crypto/implementations (since those would be called at some point). However since other code is now callinglib/crypto/directly, that assumption may no longer hold.Quoted 4 lines
*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.
Quoted 5 lines
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
Quoted 43 lines · Eric Biggers
Quoted 36 lines · Joachim Vandersmissen
Hi Eric, David,
Quoted 15 lines · Eric Biggers
Quoted 2 lines · David Howells
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)Quoted 4 lines
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 oflib/crypto/, it is possible to make an argument that thetestmgr.cself-tests cover thelib/crypto/implementations (since those would be called at some point). However since other code is now callinglib/crypto/directly, that assumption may no longer hold.Quoted 4 lines
*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.
Quoted 5 lines
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.
Quoted 3 lines
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.
Signature · 4 lines
Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc
Quoted 48 lines · Simo Sorce
Quoted 43 lines · Eric Biggers
Quoted 36 lines · Joachim Vandersmissen
Hi Eric, David,
Quoted 15 lines · Eric Biggers
Quoted 2 lines · David Howells
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)Quoted 4 lines
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 oflib/crypto/, it is possible to make an argument that thetestmgr.cself-tests cover thelib/crypto/implementations (since those would be called at some point). However since other code is now callinglib/crypto/directly, that assumption may no longer hold.Quoted 4 lines
*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.
Quoted 5 lines
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.Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
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
Quoted 9 lines · Joachim Vandersmissen
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 oflib/crypto/, it is possible to make an argument that thetestmgr.cself-tests cover thelib/crypto/implementations (since those would be called at some point). However since other code is now callinglib/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