linux-kernel - Re: [PATCH v11 4/8] 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: <20260106081029.GE2630@sol>
Date: Tue, 6 Jan 2026 00:10:29 -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 v11 4/8] modsign: Enable ML-DSA module signing

On Mon, Jan 05, 2026 at 03:21:29PM +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)").

The ML-DSA specification specifies the XOFs used.  This has nothing to
do with the API.

> +config MODULE_SIG_KEY_TYPE_MLDSA_44
> +	bool "ML-DSA (Dilithium) 44"
> +	select CRYPTO_MLDSA
> +	help
> +	  Use an ML-DSA (Dilithium) 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 (Dilithium) 65"
> +	select CRYPTO_MLDSA
> +	help
> +	  Use an ML-DSA (Dilithium) 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 (Dilithium) 87"
> +	select CRYPTO_MLDSA
> +	help
> +	  Use an ML-DSA (Dilithium) 87 key (NIST FIPS 204) for module signing
> +	  with a SHAKE256 'hash' of the authenticatedAttributes.

Kind of weird naming here.  We don't have "AES (Rijndael) 256" and
"SHA-3 (Keccak) 512".  We have AES-256 and SHA3-256.

Similarly, these should be ML-DSA-44, etc.

Yes, NIST went with boring names instead of the original cool names.
That's just how it is.

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.)

- Eric