Allow ML-DSA module signing to be enabled.
Note that openssl's CMS_*() function suite does not, as of openssl-3.5.1,
support the use of CMS_NOATTR with ML-DSA, so the prohibition against using
authenticatedAttributes with module signing has to be removed. The
selected digest then applies only to the algorithm used to calculate the
digest stored in the messageDigest attribute.
The ML-DSA algorithm uses its own internal choice of digest (SHAKE256)
without regard to what's specified in the CMS message. This is, in theory,
configurable, but there's currently no hook in the crypto_sig API to do
that, though possibly it could be done by parameterising the name of the
algorithm, e.g. ("mldsa87(sha512)").
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Biggers <ebiggers@kernel.org>
cc: Lukas Wunner <lukas@wunner.de>
cc: Ignat Korchagin <ignat@cloudflare.com>
cc: Stephan Mueller <smueller@chronox.de>
cc: Herbert Xu <herbert@gondor.apana.org.au>
cc: keyrings@vger.kernel.org
cc: linux-crypto@vger.kernel.org
---
Documentation/admin-guide/module-signing.rst | 16 +++++----
certs/Kconfig | 21 ++++++++++++
certs/Makefile | 3 ++
crypto/asymmetric_keys/pkcs7_verify.c | 4 ---
scripts/sign-file.c | 34 +++++++++++++++-----
5 files changed, 59 insertions(+), 19 deletions(-)
diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst
index a8667a777490..7f2f127dc76f 100644
--- a/Documentation/admin-guide/module-signing.rst
+++ b/Documentation/admin-guide/module-signing.rst
@@ -28,10 +28,12 @@ trusted userspace bits.
This facility uses X.509 ITU-T standard certificates to encode the public keys
involved. The signatures are not themselves encoded in any industrial standard
-type. The built-in facility currently only supports the RSA & NIST P-384 ECDSA
-public key signing standard (though it is pluggable and permits others to be
-used). The possible hash algorithms that can be used are SHA-2 and SHA-3 of
-sizes 256, 384, and 512 (the algorithm is selected by data in the signature).
+type. The built-in facility currently only supports the RSA, NIST P-384 ECDSA
+and NIST FIPS-204 ML-DSA public key signing standards (though it is pluggable
+and permits others to be used). For RSA and ECDSA, the possible hash
+algorithms that can be used are SHA-2 and SHA-3 of sizes 256, 384, and 512 (the
+algorithm is selected by data in the signature); ML-DSA does its own hashing,
+but is allowed to be used with a SHA512 hash for signed attributes.
==========================
@@ -146,9 +148,9 @@ into vmlinux) using parameters in the::
file (which is also generated if it does not already exist).
-One can select between RSA (``MODULE_SIG_KEY_TYPE_RSA``) and ECDSA
-(``MODULE_SIG_KEY_TYPE_ECDSA``) to generate either RSA 4k or NIST
-P-384 keypair.
+One can select between RSA (``MODULE_SIG_KEY_TYPE_RSA``), ECDSA
+(``MODULE_SIG_KEY_TYPE_ECDSA``) and ML-DSA (``MODULE_SIG_KEY_TYPE_MLDSA_*``) to
+generate an RSA 4k, a NIST P-384 keypair or an ML-DSA 44, 65 or 87 keypair.
It is strongly recommended that you provide your own x509.genkey file.
diff --git a/certs/Kconfig b/certs/Kconfig
index 78307dc25559..67a5786423b5 100644
--- a/certs/Kconfig
+++ b/certs/Kconfig
@@ -39,6 +39,27 @@ config MODULE_SIG_KEY_TYPE_ECDSA
Note: Remove all ECDSA signing keys, e.g. certs/signing_key.pem,
when falling back to building Linux 5.14 and older kernels.
+config MODULE_SIG_KEY_TYPE_MLDSA_44
+ bool "ML-DSA-44"
+ select CRYPTO_MLDSA
+ help
+ Use an ML-DSA-44 key (NIST FIPS 204) for module signing
+ with a SHAKE256 'hash' of the authenticatedAttributes.
+
+config MODULE_SIG_KEY_TYPE_MLDSA_65
+ bool "ML-DSA-65"
+ select CRYPTO_MLDSA
+ help
+ Use an ML-DSA-65 key (NIST FIPS 204) for module signing
+ with a SHAKE256 'hash' of the authenticatedAttributes.
+
+config MODULE_SIG_KEY_TYPE_MLDSA_87
+ bool "ML-DSA-87"
+ select CRYPTO_MLDSA
+ help
+ Use an ML-DSA-87 key (NIST FIPS 204) for module signing
+ with a SHAKE256 'hash' of the authenticatedAttributes.
+
endchoice
config SYSTEM_TRUSTED_KEYRING
diff --git a/certs/Makefile b/certs/Makefile
index f6fa4d8d75e0..3ee1960f9f4a 100644
--- a/certs/Makefile
+++ b/certs/Makefile
@@ -43,6 +43,9 @@ targets += x509_certificate_list
ifeq ($(CONFIG_MODULE_SIG_KEY),certs/signing_key.pem)
keytype-$(CONFIG_MODULE_SIG_KEY_TYPE_ECDSA) := -newkey ec -pkeyopt ec_paramgen_curve:secp384r1
+keytype-$(CONFIG_MODULE_SIG_KEY_TYPE_MLDSA_44) := -newkey ml-dsa-44
+keytype-$(CONFIG_MODULE_SIG_KEY_TYPE_MLDSA_65) := -newkey ml-dsa-65
+keytype-$(CONFIG_MODULE_SIG_KEY_TYPE_MLDSA_87) := -newkey ml-dsa-87
quiet_cmd_gen_key = GENKEY $@
cmd_gen_key = openssl req -new -nodes -utf8 -$(CONFIG_MODULE_SIG_HASH) -days 36500 \
diff --git a/crypto/asymmetric_keys/pkcs7_verify.c b/crypto/asymmetric_keys/pkcs7_verify.c
index 46eee9811023..3896e24423f9 100644
--- a/crypto/asymmetric_keys/pkcs7_verify.c
+++ b/crypto/asymmetric_keys/pkcs7_verify.c
@@ -442,10 +442,6 @@ int pkcs7_verify(struct pkcs7_message *pkcs7,
pr_warn("Invalid module sig (not pkcs7-data)\n");
return -EKEYREJECTED;
}
- if (pkcs7->have_authattrs) {
- pr_warn("Invalid module sig (has authattrs)\n");
- return -EKEYREJECTED;
- }
break;
case VERIFYING_FIRMWARE_SIGNATURE:
if (pkcs7->data_type != OID_data) {
diff --git a/scripts/sign-file.c b/scripts/sign-file.c
index 7070245edfc1..547b97097230 100644
--- a/scripts/sign-file.c
+++ b/scripts/sign-file.c
@@ -315,18 +315,36 @@ int main(int argc, char **argv)
ERR(!digest_algo, "EVP_get_digestbyname");
#ifndef USE_PKCS7
+
+ unsigned int flags =
+ CMS_NOCERTS |
+ CMS_PARTIAL |
+ CMS_BINARY |
+ CMS_DETACHED |
+ CMS_STREAM |
+ CMS_NOSMIMECAP |
+ CMS_NO_SIGNING_TIME |
+ use_keyid;
+
+ if ((EVP_PKEY_is_a(private_key, "ML-DSA-44") ||
+ EVP_PKEY_is_a(private_key, "ML-DSA-65") ||
+ EVP_PKEY_is_a(private_key, "ML-DSA-87")) &&
+ OPENSSL_VERSION_MAJOR < 4) {
+ /* ML-DSA + CMS_NOATTR is not supported in openssl-3.5
+ * and before.
+ */
+ use_signed_attrs = 0;
+ }
+
+ flags |= use_signed_attrs;
+
/* Load the signature message from the digest buffer. */
- cms = CMS_sign(NULL, NULL, NULL, NULL,
- CMS_NOCERTS | CMS_PARTIAL | CMS_BINARY |
- CMS_DETACHED | CMS_STREAM);
+ cms = CMS_sign(NULL, NULL, NULL, NULL, flags);
ERR(!cms, "CMS_sign");
- ERR(!CMS_add1_signer(cms, x509, private_key, digest_algo,
- CMS_NOCERTS | CMS_BINARY |
- CMS_NOSMIMECAP | use_keyid |
- use_signed_attrs),
+ ERR(!CMS_add1_signer(cms, x509, private_key, digest_algo, flags),
"CMS_add1_signer");
- ERR(CMS_final(cms, bm, NULL, CMS_NOCERTS | CMS_BINARY) != 1,
+ ERR(CMS_final(cms, bm, NULL, flags) != 1,
"CMS_final");
#elseOn Tue, Jan 20, 2026 at 02:50:51PM +0000, David Howells wrote:
> The ML-DSA algorithm uses its own internal choice of digest (SHAKE256)
> without regard to what's specified in the CMS message. This is, in theory,
> configurable, but there's currently no hook in the crypto_sig API to do
> that, though possibly it could be done by parameterising the name of the
> algorithm, e.g. ("mldsa87(sha512)").
As I mentioned on v11, this paragraph doesn't really make sense, since
the XOF is part of the ML-DSA specification. Sure, you saw some
component of ML-DSA which could, in principle, swapped out with some
other component to create a new algorithm which would not be "ML-DSA".
But the XOF isn't really unique there.
> +config MODULE_SIG_KEY_TYPE_MLDSA_44
> + bool "ML-DSA-44"
> + select CRYPTO_MLDSA
> + help
> + Use an ML-DSA-44 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the authenticatedAttributes.
Let me reiterate my comment from v11:
Also unclear why the above help text mentions anything about SHAKE256 or
the authenticatedAttributes. That's an implementation detail. (And
the CMS specification calls them signed attributes anyway.)
I'll also note that your signing program doesn't actually produce signed
attributes if the OpenSSL version is sufficiently new.
> +config MODULE_SIG_KEY_TYPE_MLDSA_65
> + bool "ML-DSA-65"
> + select CRYPTO_MLDSA
> + help
> + Use an ML-DSA-65 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the authenticatedAttributes.
> +
> +config MODULE_SIG_KEY_TYPE_MLDSA_87
> + bool "ML-DSA-87"
> + select CRYPTO_MLDSA
> + help
> + Use an ML-DSA-87 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the authenticatedAttributes.
Do all three ML-DSA parameter sets really need to be supported for
module signing? How will distros decide which one to use?
Any chance that ML-DSA-65 would be good enough for everyone? That's the
one that I'm seeing recommended the most.
> diff --git a/scripts/sign-file.c b/scripts/sign-file.c
> index 7070245edfc1..547b97097230 100644
> --- a/scripts/sign-file.c
> +++ b/scripts/sign-file.c
> @@ -315,18 +315,36 @@ int main(int argc, char **argv)
> ERR(!digest_algo, "EVP_get_digestbyname");
>
> #ifndef USE_PKCS7
> +
> + unsigned int flags =
> + CMS_NOCERTS |
> + CMS_PARTIAL |
> + CMS_BINARY |
> + CMS_DETACHED |
> + CMS_STREAM |
> + CMS_NOSMIMECAP |
> + CMS_NO_SIGNING_TIME |
> + use_keyid;
> +
> + if ((EVP_PKEY_is_a(private_key, "ML-DSA-44") ||
> + EVP_PKEY_is_a(private_key, "ML-DSA-65") ||
> + EVP_PKEY_is_a(private_key, "ML-DSA-87")) &&
> + OPENSSL_VERSION_MAJOR < 4) {
> + /* ML-DSA + CMS_NOATTR is not supported in openssl-3.5
> + * and before.
> + */
> + use_signed_attrs = 0;
> + }
> +
> + flags |= use_signed_attrs;
If OpenSSL 3.5 is the last version that doesn't support the noattr case,
that would mean that OpenSSL 3.6 does support it, right? OpenSSL 3.6
was released several months ago. Yet the above code requires version 4.
Either way, this version-dependent logic is a bit fragile: users will
suddenly get different behavior on OpenSSL version updates. And once
everyone has updated, the old code will no longer be tested.
How about we just support the new way only? That would be simpler, and
it sounds like it's already supported by the latest OpenSSL.
- Eric
Eric Biggers <ebiggers@kernel.org> wrote: > If OpenSSL 3.5 is the last version that doesn't support the noattr case, > that would mean that OpenSSL 3.6 does support it, right? OpenSSL 3.6 > was released several months ago. Yet the above code requires version 4. 3.5 and 3.6 support ML-DSA, but not with CMS_NOATTR, so I need to update this. Version 4 will support ML-DSA with CMS_NOATTR, but that's not yet tagged. > How about we just support the new way only? That would be simpler, and > it sounds like it's already supported by the latest OpenSSL. Depends what you mean by "latest OpenSSL". Latest in git, yes; latest in distributions that people can simply install as an rpm/deb/etc., no. Now, assuming OpenSSL releases v4 sometime in the spring, I would probably be fine with saying you have to have OpenSSL v4 if you want ML-DSA; but others might have a different opinion. David
© 2016 - 2026 Red Hat, Inc.