Hi Herbert, Eric, et al.,

Building on the SHA-3 lib-crypto patches now in Eric's tree, here's a set of
patches does the following:

 (1) Add SHAKE-256 crypto_sig support, generating 32-byte fixed output.  The
     XOF features aren't available through this.  SHAKE-128 crypto_sig support
     isn't required for ML-DSA, so I haven't implemented that at this time.

 (2) Add ML-DSA signature verification code, extracted from Stephan
     Mueller's Leancrypto project.  The primary interface is intended to be
     through crypto_sig.

 (3) Add a simplified ML-DSA API for direct lib-crypto access.  Possibly
     this should be conditional as the main access (from PKCS#7/X.509) is
     going to be through crypto_sig.

 (4) Add a kunit test in three instalments (due to size) to add some
     testing for the three different levels of ML-DSA (44, 65 and 87).

 (5) Modify PKCS#7 support to allow kernel module signatures to carry
     authenticatedAttributes as OpenSSL refuses to let them be opted out of
     for ML-DSA (CMS_NOATTR).  This adds an extra digest calculation to the
     process.

 (6) Modify PKCS#7 to pass the authenticatedAttributes directly to the
     ML-DSA algorithm rather than passing over a digest as is done with RSA
     as ML-DSA wants to do its own hashing and will add other stuff into
     the hash.  We could use hashML-DSA or an external mu instead, but they
     aren't standardised for CMS yet.

 (7) Add support to the PKCS#7 and X.509 parsers for ML-DSA.

 (8) Modify sign-file to handle OpenSSL not permitting CMS_NOATTR with
     ML-DSA.

 (9) Allow SHA-3 algorithms, including SHAKE256, to be used for the message
     digest and add ML-DSA to the choice of algorithm with which to sign.

With that, ML-DSA signing appears to work.

This is based on Eric's libcrypto-next branch.

The patches can also be found here:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-pqc

David

Changes
=======
ver #9)
 - ML-DSA changes:
   - Separate output into four modules (1 common, 3 strength-specific).
     - Solves Kconfig issue with needing to select at least one strength.
   - Separate the strength-specific crypto-lib APIs.
     - This is now generated by preprocessor-templating.
   - Remove the multiplexor code.
   - Multiplex the crypto-lib APIs by C type.
 - Fix the PKCS#7/X.509 code to have the correct algo names.

ver #8)
 - Moved the ML-DSA code to lib/crypto/mldsa/.
 - Renamed some bits from ml-dsa to mldsa.
 - Created a simplified API and placed that in include/crypto/mldsa.h.
 - Made the testing code use the simplified API.
 - Fixed a warning about implicitly casting between uint16_t and __le16.

ver #7)
 - Rebased on Eric's tree as that now contains all the necessary SHA-3
   infrastructure and drop the SHA-3 patches from here.
 - Added a minimal patch to provide shake256 support for crypto_sig.
 - Got rid of the memory allocation wrappers.
 - Removed the ML-DSA keypair generation code and the signing code, leaving
   only the signature verification code.
 - Removed the secret key handling code.
 - Removed the secret keys from the kunit tests and the signing testing.
 - Removed some unused bits from the ML-DSA code.
 - Downgraded the kdoc comments to ordinary comments, but keep the markup
   for easier comparison to Leancrypto.

ver #6)
 - Added a patch to make the jitterentropy RNG use lib/sha3.
 - Added back the crypto/sha3_generic changes.
 - Added ML-DSA implementation (still needs more cleanup).
 - Added kunit test for ML-DSA.
 - Modified PKCS#7 to accommodate ML-DSA.
 - Modified PKCS#7 and X.509 to allow ML-DSA to be specified and used.
 - Modified sign-file to not use CMS_NOATTR with ML-DSA.
 - Allowed SHA3 and SHAKE* algorithms for module signing default.
 - Allowed ML-DSA-{44,65,87} to be selected as the module signing default.

ver #5)
 - Fix gen-hash-testvecs.py to correctly handle algo names that contain a
   dash.
 - Fix gen-hash-testvecs.py to not generate HMAC for SHA3-* or SHAKE* as
   these don't currently have HMAC variants implemented.
 - Fix algo names to be correct.
 - Fix kunit module description as it now tests all SHA3 variants.

ver #4)
 - Fix a couple of arm64 build problems.
 - Doc fixes:
   - Fix the description of the algorithm to be closer to the NIST spec's
     terminology.
   - Don't talk of finialising the context for XOFs.
   - Don't say "Return: None".
   - Declare the "Context" to be "Any context" and make no mention of the
     fact that it might use the FPU.
   - Change "initialise" to "initialize".
   - Don't warn that the context is relatively large for stack use.
 - Use size_t for size parameters/variables.
 - Make the module_exit unconditional.
 - Dropped the crypto/ dir-affecting patches for the moment.

ver #3)
 - Renamed conflicting arm64 functions.
 - Made a separate wrapper API for each algorithm in the family.
 - Removed sha3_init(), sha3_reinit() and sha3_final().
 - Removed sha3_ctx::digest_size.
 - Renamed sha3_ctx::partial to sha3_ctx::absorb_offset.
 - Refer to the output of SHAKE* as "output" not "digest".
 - Moved the Iota transform into the one-round function.
 - Made sha3_update() warn if called after sha3_squeeze().
 - Simplified the module-load test to not do update after squeeze.
 - Added Return: and Context: kdoc statements and expanded the kdoc
   headers.
 - Added an API description document.
 - Overhauled the kunit tests.
   - Only have one kunit test.
   - Only call the general hash tester on one algo.
   - Add separate simple cursory checks for the other algos.
   - Add resqueezing tests.
   - Add some NIST example tests.
 - Changed crypto/sha3_generic to use this
 - Added SHAKE128/256 to crypto/sha3_generic and crypto/testmgr
 - Folded struct sha3_state into struct sha3_ctx.

ver #2)
  - Simplify the endianness handling.
  - Rename sha3_final() to sha3_squeeze() and don't clear the context at the
    end as it's permitted to continue calling sha3_final() to extract
    continuations of the digest (needed by ML-DSA).
  - Don't reapply the end marker to the hash state in continuation
    sha3_squeeze() unless sha3_update() gets called again (needed by
    ML-DSA).
  - Give sha3_squeeze() the amount of digest to produce as a parameter
    rather than using ctx->digest_size and don't return the amount digested.
  - Reimplement sha3_final() as a wrapper around sha3_squeeze() that
    extracts ctx->digest_size amount of digest and then zeroes out the
    context.  The latter is necessary to avoid upsetting
    hash-test-template.h.
  - Provide a sha3_reinit() function to clear the state, but to leave the
    parameters that indicate the hash properties unaffected, allowing for
    reuse.
  - Provide a sha3_set_digestsize() function to change the size of the
    digest to be extracted by sha3_final().  sha3_squeeze() takes a
    parameter for this instead.
  - Don't pass the digest size as a parameter to shake128/256_init() but
    rather default to 128/256 bits as per the function name.
  - Provide a sha3_clear() function to zero out the context.

David Howells (9):
  crypto: Add support for shake256 through crypto_shash
  crypto: Add ML-DSA/Dilithium verify support
  mldsa: Add a simpler API
  crypto: Add ML-DSA-44 pure rejection test vectors as a kunit test
  crypto: Add ML-DSA-65 pure rejection test vectors as a kunit test
  crypto: Add ML-DSA-87 pure rejection test vectors as a kunit test
  pkcs7: Allow the signing algo to calculate the digest itself
  pkcs7, x509: Add ML-DSA support
  modsign: Enable ML-DSA module signing

 Documentation/admin-guide/module-signing.rst  |   15 +-
 Documentation/crypto/index.rst                |    1 +
 Documentation/crypto/mldsa.rst                |  143 +
 certs/Kconfig                                 |   27 +
 certs/Makefile                                |    3 +
 crypto/asymmetric_keys/pkcs7_parser.c         |   19 +-
 crypto/asymmetric_keys/pkcs7_verify.c         |   52 +-
 crypto/asymmetric_keys/public_key.c           |    7 +
 crypto/asymmetric_keys/x509_cert_parser.c     |   24 +
 crypto/sha3.c                                 |   42 +
 include/crypto/mldsa.h                        |   50 +
 include/crypto/public_key.h                   |    1 +
 include/linux/oid_registry.h                  |    5 +
 kernel/module/Kconfig                         |    5 +
 lib/crypto/Kconfig                            |    1 +
 lib/crypto/Makefile                           |    2 +
 lib/crypto/mldsa/Kconfig                      |   29 +
 lib/crypto/mldsa/Makefile                     |   20 +
 lib/crypto/mldsa/crypto_mldsa_44.c            |  166 +
 lib/crypto/mldsa/crypto_mldsa_65.c            |  166 +
 lib/crypto/mldsa/crypto_mldsa_87.c            |  166 +
 lib/crypto/mldsa/dilithium.h                  |  304 +
 lib/crypto/mldsa/dilithium_44.c               |   34 +
 lib/crypto/mldsa/dilithium_44.h               |  291 +
 lib/crypto/mldsa/dilithium_65.c               |   34 +
 lib/crypto/mldsa/dilithium_65.h               |  291 +
 lib/crypto/mldsa/dilithium_87.c               |   34 +
 lib/crypto/mldsa/dilithium_87.h               |  291 +
 lib/crypto/mldsa/dilithium_common.c           |  117 +
 lib/crypto/mldsa/dilithium_debug.h            |   49 +
 lib/crypto/mldsa/dilithium_ntt.c              |   89 +
 lib/crypto/mldsa/dilithium_ntt.h              |   35 +
 lib/crypto/mldsa/dilithium_pack.h             |  119 +
 lib/crypto/mldsa/dilithium_poly.c             |  377 +
 lib/crypto/mldsa/dilithium_poly.h             |  181 +
 lib/crypto/mldsa/dilithium_poly_c.h           |  141 +
 lib/crypto/mldsa/dilithium_poly_common.h      |   35 +
 lib/crypto/mldsa/dilithium_polyvec.h          |  343 +
 lib/crypto/mldsa/dilithium_polyvec_c.h        |   81 +
 lib/crypto/mldsa/dilithium_reduce.h           |   85 +
 lib/crypto/mldsa/dilithium_rounding.c         |  128 +
 lib/crypto/mldsa/dilithium_service_helpers.h  |   99 +
 lib/crypto/mldsa/dilithium_signature_c.c      |  279 +
 lib/crypto/mldsa/dilithium_signature_c.h      |   37 +
 lib/crypto/mldsa/dilithium_signature_impl.h   |  370 +
 lib/crypto/mldsa/dilithium_type.h             |  121 +
 lib/crypto/mldsa/dilithium_zetas.c            |   68 +
 lib/crypto/mldsa/mldsa_api.c                  |  168 +
 .../mldsa/signature_domain_separation.c       |  204 +
 .../mldsa/signature_domain_separation.h       |   30 +
 lib/crypto/tests/Kconfig                      |   10 +
 lib/crypto/tests/Makefile                     |    1 +
 lib/crypto/tests/mldsa_kunit.c                |  105 +
 .../tests/mldsa_pure_rejection_vectors_44.h   |  489 ++
 .../tests/mldsa_pure_rejection_vectors_65.h   | 4741 ++++++++++++
 .../tests/mldsa_pure_rejection_vectors_87.h   | 6456 +++++++++++++++++
 scripts/sign-file.c                           |   26 +-
 57 files changed, 17171 insertions(+), 36 deletions(-)
 create mode 100644 Documentation/crypto/mldsa.rst
 create mode 100644 include/crypto/mldsa.h
 create mode 100644 lib/crypto/mldsa/Kconfig
 create mode 100644 lib/crypto/mldsa/Makefile
 create mode 100644 lib/crypto/mldsa/crypto_mldsa_44.c
 create mode 100644 lib/crypto/mldsa/crypto_mldsa_65.c
 create mode 100644 lib/crypto/mldsa/crypto_mldsa_87.c
 create mode 100644 lib/crypto/mldsa/dilithium.h
 create mode 100644 lib/crypto/mldsa/dilithium_44.c
 create mode 100644 lib/crypto/mldsa/dilithium_44.h
 create mode 100644 lib/crypto/mldsa/dilithium_65.c
 create mode 100644 lib/crypto/mldsa/dilithium_65.h
 create mode 100644 lib/crypto/mldsa/dilithium_87.c
 create mode 100644 lib/crypto/mldsa/dilithium_87.h
 create mode 100644 lib/crypto/mldsa/dilithium_common.c
 create mode 100644 lib/crypto/mldsa/dilithium_debug.h
 create mode 100644 lib/crypto/mldsa/dilithium_ntt.c
 create mode 100644 lib/crypto/mldsa/dilithium_ntt.h
 create mode 100644 lib/crypto/mldsa/dilithium_pack.h
 create mode 100644 lib/crypto/mldsa/dilithium_poly.c
 create mode 100644 lib/crypto/mldsa/dilithium_poly.h
 create mode 100644 lib/crypto/mldsa/dilithium_poly_c.h
 create mode 100644 lib/crypto/mldsa/dilithium_poly_common.h
 create mode 100644 lib/crypto/mldsa/dilithium_polyvec.h
 create mode 100644 lib/crypto/mldsa/dilithium_polyvec_c.h
 create mode 100644 lib/crypto/mldsa/dilithium_reduce.h
 create mode 100644 lib/crypto/mldsa/dilithium_rounding.c
 create mode 100644 lib/crypto/mldsa/dilithium_service_helpers.h
 create mode 100644 lib/crypto/mldsa/dilithium_signature_c.c
 create mode 100644 lib/crypto/mldsa/dilithium_signature_c.h
 create mode 100644 lib/crypto/mldsa/dilithium_signature_impl.h
 create mode 100644 lib/crypto/mldsa/dilithium_type.h
 create mode 100644 lib/crypto/mldsa/dilithium_zetas.c
 create mode 100644 lib/crypto/mldsa/mldsa_api.c
 create mode 100644 lib/crypto/mldsa/signature_domain_separation.c
 create mode 100644 lib/crypto/mldsa/signature_domain_separation.h
 create mode 100644 lib/crypto/tests/mldsa_kunit.c
 create mode 100644 lib/crypto/tests/mldsa_pure_rejection_vectors_44.h
 create mode 100644 lib/crypto/tests/mldsa_pure_rejection_vectors_65.h
 create mode 100644 lib/crypto/tests/mldsa_pure_rejection_vectors_87.h

Hi Herbert,

I'm wondering from where I should invoke the FIPS tests for ML-DSA.

Currently, the asymmetric key type has some FIPS selftests for RSA and ECDSA
built into it, but I wonder if that's the best way.  The problem is that it
does the selftest during module init - but that can only test whatever
algorithms are built into the base kernel image and initialised at the time
late_initcall() happens.

It might be better to put the tests into the algorithm modules themselves -
but that then has a potential circular dependency issue.  However, that might
not matter as the asymmetric key type won't be built as a module and will be
built into the kernel (though some of the components such as X.509 and PKCS#7
can be built as modules).

If I don't involve X.509/PKCS#7 in the selftest, then doing it from the ML-DSA
modules during module init would be fine.

Do you (or anyone else) have any thoughts?

David

On Mon, Nov 17, 2025 at 04:01:39PM +0000, David Howells wrote:
> Hi Herbert,
> 
> I'm wondering from where I should invoke the FIPS tests for ML-DSA.
> 
> Currently, the asymmetric key type has some FIPS selftests for RSA and ECDSA
> built into it, but I wonder if that's the best way.  The problem is that it
> does the selftest during module init - but that can only test whatever
> algorithms are built into the base kernel image and initialised at the time
> late_initcall() happens.
> 
> It might be better to put the tests into the algorithm modules themselves -
> but that then has a potential circular dependency issue.  However, that might
> not matter as the asymmetric key type won't be built as a module and will be
> built into the kernel (though some of the components such as X.509 and PKCS#7
> can be built as modules).
> 
> If I don't involve X.509/PKCS#7 in the selftest, then doing it from the ML-DSA
> modules during module init would be fine.
> 
> Do you (or anyone else) have any thoughts?

The FIPS self-test should just go in the algorithm module itself and
test ML-DSA directly.  See the other lib/crypto/ FIPS self-tests.
Please check the FIPS Implementation Guidance documentation to see what
is needed; it isn't actually very much.

- Eric

Hi Stephen,

Can you pick up my keys-pqc branch for linux-next please?  It can be found at:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/
	keys-pqc

Note that it's based on Eric Bigger's libcrypto/lbcrypto-next branch which I
believe you already have in order to get SHA-3/SHAKE support.

Thanks,
David

On Mon, Nov 17, 2025 at 03:22:03PM +0000, David Howells wrote:
> Hi Stephen,
> 
> Can you pick up my keys-pqc branch for linux-next please?  It can be found at:
> 
> 	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/
> 	keys-pqc
> 
> Note that it's based on Eric Bigger's libcrypto/lbcrypto-next branch which I
> believe you already have in order to get SHA-3/SHAKE support.
> 

I don't really see the point yet, since this isn't going to be ready for
the next merge window anyway.

- Eric

Hi David,

On Mon, 17 Nov 2025 09:11:26 -0800 Eric Biggers <ebiggers@kernel.org> wrote:
>
> On Mon, Nov 17, 2025 at 03:22:03PM +0000, David Howells wrote:
> > 
> > Can you pick up my keys-pqc branch for linux-next please?  It can be found at:
> > 
> > 	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/
> > 	keys-pqc
> > 
> > Note that it's based on Eric Bigger's libcrypto/lbcrypto-next branch which I
> > believe you already have in order to get SHA-3/SHAKE support.
> 
> I don't really see the point yet, since this isn't going to be ready for
> the next merge window anyway.

Yeah, if it is not going into the next merge window, then I don't want
it until after that merge window closes, OK?

-- 
Cheers,
Stephen Rothwell

On Thu, Nov 20, 2025 at 08:53:41PM +1100, Stephen Rothwell wrote:
> Hi David,
> 
> On Mon, 17 Nov 2025 09:11:26 -0800 Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > On Mon, Nov 17, 2025 at 03:22:03PM +0000, David Howells wrote:
> > > 
> > > Can you pick up my keys-pqc branch for linux-next please?  It can be found at:
> > > 
> > > 	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/
> > > 	keys-pqc
> > > 
> > > Note that it's based on Eric Bigger's libcrypto/lbcrypto-next branch which I
> > > believe you already have in order to get SHA-3/SHAKE support.
> > 
> > I don't really see the point yet, since this isn't going to be ready for
> > the next merge window anyway.
> 
> Yeah, if it is not going into the next merge window, then I don't want
> it until after that merge window closes, OK?

Makes sense to me.  David, with
https://lore.kernel.org/r/20251120003653.335863-2-ebiggers@kernel.org
we're getting closer, but it's still too late for 6.19.  We need proper
tests to be added at the same time as the ML-DSA implementation itself.
The higher-level parts such as crypto/asymmetric_keys/ need review too.
Also, lib/crypto/ changes should go through the libcrypto tree.

wycheproof has negative test vectors for ML-DSA edge cases.  We maybe
could borrow those.  Note that ML-DSA keys and signatures are very
large, which results in huge files for the test vectors.  I'd also like
to keep the size down, but we might not have much choice there.

I'm also working to get another crypto-oriented developer, who doesn't
normally work on the Linux kernel, to review my ML-DSA code.  (I don't
think I was going to have any chance at getting anyone to look at the
original 4800-line submission, but with the 600-line one it's feasible.)

It's also worth noting that this is ML-DSA, not ML-KEM.  The
cryptographic community generally views upgrading to quantum-resistant
key encapsulation (e.g. ML-KEM) as more urgent than upgrading to
quantum-resistant signatures (e.g. ML-DSA).  I assume you have a reason
why you want the signatures.  That's fine, and I'm okay with ML-DSA
support being added.  But we shouldn't rush it in.

- Eric