| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <IA4PR84MB4011C832FD34CE55C3BA3258ABC1A@IA4PR84MB4011.NAMPRD84.PROD.OUTLOOK.COM>
Date: Sun, 9 Nov 2025 19:42:02 +0000
From: "Elliott, Robert (Servers)" <elliott@....com>
To: David Howells <dhowells@...hat.com>
CC: Herbert Xu <herbert@...dor.apana.org.au>,
Eric Biggers
<ebiggers@...nel.org>,
Luis Chamberlain <mcgrof@...nel.org>,
Petr Pavlu
<petr.pavlu@...e.com>, Daniel Gomez <da.gomez@...nel.org>,
Sami Tolvanen
<samitolvanen@...gle.com>,
"Jason A . Donenfeld" <Jason@...c4.com>,
"Ard
Biesheuvel" <ardb@...nel.org>,
Stephan Mueller <smueller@...onox.de>,
"Lukas
Wunner" <lukas@...ner.de>,
Ignat Korchagin <ignat@...udflare.com>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
"linux-modules@...r.kernel.org" <linux-modules@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v7 8/8] modsign: Enable ML-DSA module signing
> -----Original Message-----
> From: David Howells <dhowells@...hat.com>
> Sent: Friday, November 7, 2025 4:06 AM
> Cc: dhowells@...hat.com; Herbert Xu <herbert@...dor.apana.org.au>; Eric
> Biggers <ebiggers@...nel.org>; Luis Chamberlain <mcgrof@...nel.org>;
> Petr Pavlu <petr.pavlu@...e.com>; Daniel Gomez <da.gomez@...nel.org>;
> Sami Tolvanen <samitolvanen@...gle.com>; Jason A . Donenfeld
> <Jason@...c4.com>; Ard Biesheuvel <ardb@...nel.org>; Stephan Mueller
> <smueller@...onox.de>; Lukas Wunner <lukas@...ner.de>; Ignat Korchagin
> <ignat@...udflare.com>; linux-crypto@...r.kernel.org;
> keyrings@...r.kernel.org; linux-modules@...r.kernel.org; linux-
> kernel@...r.kernel.org
> Subject: [PATCH v7 8/8] modsign: Enable ML-DSA module signing
>
>
> 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. ("ml-dsa87(sha512)").
>
> Signed-off-by: David Howells <dhowells@...hat.com>
> cc: Lukas Wunner <lukas@...ner.de>
> cc: Ignat Korchagin <ignat@...udflare.com>
> cc: Stephan Mueller <smueller@...onox.de>
> cc: Eric Biggers <ebiggers@...nel.org>
> cc: Herbert Xu <herbert@...dor.apana.org.au>
> cc: keyrings@...r.kernel.org
> cc: linux-crypto@...r.kernel.org
> ---
> Documentation/admin-guide/module-signing.rst | 15 ++++++++-------
> certs/Kconfig | 24
> ++++++++++++++++++++++++
> certs/Makefile | 3 +++
> crypto/asymmetric_keys/pkcs7_verify.c | 4 ----
> kernel/module/Kconfig | 5 +++++
> scripts/sign-file.c | 26
> ++++++++++++++++++--------
> 6 files changed, 58 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/admin-guide/module-signing.rst
> b/Documentation/admin-guide/module-signing.rst
> index a8667a777490..6daff80c277b 100644
> --- a/Documentation/admin-guide/module-signing.rst
> +++ b/Documentation/admin-guide/module-signing.rst
> @@ -28,10 +28,11 @@ 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 (Dilithium) 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 uses SHAKE256.
>
>
> ==========================
> @@ -146,9 +147,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_ML_DSA``) to
> +generate an RSA 4k, a NIST P-384 keypair or an ML-DSA keypair.
>
> It is strongly recommended that you provide your own x509.genkey file.
>
> diff --git a/certs/Kconfig b/certs/Kconfig
> index 78307dc25559..f647b944f5da 100644
> --- a/certs/Kconfig
> +++ b/certs/Kconfig
> @@ -39,6 +39,30 @@ 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_ML_DSA_44
> + bool "ML-DSA (Dilithium) 44"
> + select CRYPTO_ML_DSA
> + select LIB_SHA3
> + help
> + Use an ML-DSA (Dilithium) 44 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the message.
> +
> +config MODULE_SIG_KEY_TYPE_ML_DSA_65
> + bool "ML-DSA (Dilithium) 65"
> + select CRYPTO_ML_DSA
> + select LIB_SHA3
> + help
> + Use an ML-DSA (Dilithium) 65 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the message.
> +
> +config MODULE_SIG_KEY_TYPE_ML_DSA_87
> + bool "ML-DSA (Dilithium) 87"
> + select CRYPTO_ML_DSA
> + select LIB_SHA3
> + help
> + Use an ML-DSA (Dilithium) 87 key (NIST FIPS 204) for module signing
> + with a SHAKE256 'hash' of the message.
> +
It'd be helpful to keep the names like "ML-DSA-44" together.
I would drop the Dilithium references altogether; that was used by some
pre-standard implementations that don't necessarily interoperate with the
final standard.
...
> diff --git a/kernel/module/Kconfig b/kernel/module/Kconfig
> index 2a1beebf1d37..4b5d1601d537 100644
> --- a/kernel/module/Kconfig
> +++ b/kernel/module/Kconfig
> @@ -327,6 +327,10 @@ config MODULE_SIG_SHA3_512
> bool "SHA3-512"
> select CRYPTO_SHA3
>
> +config MODULE_SIG_SHAKE256
> + bool "SHAKE256"
> + select CRYPTO_SHA3
> +
> endchoice
>
> config MODULE_SIG_HASH
> @@ -339,6 +343,7 @@ config MODULE_SIG_HASH
> default "sha3-256" if MODULE_SIG_SHA3_256
> default "sha3-384" if MODULE_SIG_SHA3_384
> default "sha3-512" if MODULE_SIG_SHA3_512
> + default "shake256" if MODULE_SIG_SHAKE256
ML-DSA can sign any message, including a message that happens
to be a hash value already. It runs its own hash algorithm
(SHAKE256) on that message unless
* using the HashML variant that nobody likes
* using the "external mu" option, requiring confidence
that it really was done, with the correct prefix
(the context string, if any, is part of the prefix)
OpenSSL supports "external mu" with the OSSL_PARAM array
parameter OSSL_SIGNATURE_PARAM_MU, but that needs to be set
with EVP APIs.
(per the OpenSSL EVP_SIGNATURE-ML-DSA documentation page)
If the goal is to just avoid SHA-2 (e.g., running on
a CPU that only has SHA-3 acceleration), then the existing
SHA3 options accomplish that; I'm not sure offering
SHAKE256 in addition to SHA3-512 is useful.
If using a composite based on the CMS proposal, then
the message is hashed with an algorithm defined in that
proposal (for id-MLDSA87-Ed448-SHAKE256, it's
SHAKE256 truncated to 64 bytes) and then fed to each
of the signing algorithms (e.g., pure ML-DSA-87 and
pure Ed448).
That hash wouldn't qualify as an "external mu" offload for
ML-DSA since the hash output size doesn't match (ML-DSA
expects 114 bytes) and the right prefix wouldn't have been
included (Ed448 doesn't expect the message to hold the
ML-DSA prefix).
> config MODULE_COMPRESS
> bool "Module compression"
> diff --git a/scripts/sign-file.c b/scripts/sign-file.c
> index 7070245edfc1..b726581075f9 100644
> --- a/scripts/sign-file.c
> +++ b/scripts/sign-file.c
> @@ -315,18 +315,28 @@ 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"))
> + 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);
For code signing, a desirable property is reproducible builds.
For RSASSA-PKCSv1_5 (and EdDSA), that is always true.
For ECDSA, OpenSSL defaults to deterministic signing, so
sign-file inherits that behavior.
For ML-DSA, the OpenSSL library defaults to hedged mode rather
than deterministic mode, so some additional steps will be
necessary to keep it deterministic.
OpenSSL supports deterministic mode with the OSSL_PARAM array
parameter OSSL_SIGNATURE_PARAM_DETERMINISTIC, but that needs to
be set with EVP APIs.
Powered by blists - more mailing lists