linux-kernel - Re: [PATCH v13 05/12] modsign: Enable ML-DSA module signing

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260120213820.GD2657@quark>
Date: Tue, 20 Jan 2026 13:38:20 -0800
From: Eric Biggers <ebiggers@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Lukas Wunner <lukas@...ner.de>, Ignat Korchagin <ignat@...udflare.com>,
	Jarkko Sakkinen <jarkko@...nel.org>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	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>, linux-crypto@...r.kernel.org,
	keyrings@...r.kernel.org, linux-modules@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v13 05/12] modsign: Enable ML-DSA module signing

On 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