linux-kernel - Re: [PATCH v6 17/17] 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] [day] [month] [year] [list]

Message-ID: <31211.1762450662@warthog.procyon.org.uk>
Date: Thu, 06 Nov 2025 17:37:42 +0000
From: David Howells <dhowells@...hat.com>
To: Petr Pavlu <petr.pavlu@...e.com>
Cc: dhowells@...hat.com, Eric Biggers <ebiggers@...nel.org>,
    "Jason A . Donenfeld" <Jason@...c4.com>,
    Ard Biesheuvel <ardb@...nel.org>,
    Herbert Xu <herbert@...dor.apana.org.au>,
    Stephan Mueller <smueller@...onox.de>,
    Lukas Wunner <lukas@...ner.de>,
    Ignat Korchagin <ignat@...udflare.com>,
    Luis Chamberlain <mcgrof@...nel.org>,
    Daniel Gomez <da.gomez@...nel.org>,
    Sami Tolvanen <samitolvanen@...gle.com>,
    linux-crypto@...r.kernel.org, keyrings@...r.kernel.org,
    linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 17/17] modsign: Enable ML-DSA module signing

Petr Pavlu <petr.pavlu@...e.com> wrote:

> This update looks ok to me. However, I'll note some problems that
> I noticed in the original text, notably:
> 
> The text doesn't match the implementation because kernel/module/Kconfig
> still allows selecting SHA-1 for module signing. What happened is that
> commit 16ab7cb5825f ("crypto: pkcs7 - remove sha1 support") initially
> removed CONFIG_MODULE_SIG_SHA1. Then, commit f2b88bab69c8
> ("Documentation/module-signing.txt: bring up to date") removed it from
> the documentation. However, commit 203a6763ab69 ("Revert "crypto: pkcs7
> - remove sha1 support"") brought back CONFIG_MODULE_SIG_SHA1 without
> reverting the documentation update.
> 
> Another problem is that for MODULE_SIG_KEY_TYPE_ECDSA, certs/Kconfig
> contains the line
> "depends on !(MODULE_SIG_SHA256 || MODULE_SIG_SHA3_256)",
> which intends to allow ECDSA only with MODULE_SIG_SHA384,
> MODULE_SIG_SHA512, MODULE_SIG_SHA3_384 and MODULE_SIG_SHA3_512. This
> restriction was added in commit d4f5bfe20da9 ("certs: Limit
> MODULE_SIG_KEY_TYPE_ECDSA to SHA384 or SHA512") and 446b1e0b7b39
> ("module: enable automatic module signing with FIPS 202 SHA-3").
> However, the documentation suggests that ECDSA can still be used with
> SHA-2/3 of size 256.
> 
> I'll prepare fixes for these issues. For the first problem, I think we
> can drop CONFIG_MODULE_SIG_SHA1 instead of correcting the documentation.

Sounds good.

> > +	  Use an ML-DSA (Dilithium) 87 key (NIST FIPS 204) for module signing
> > +	  with a SHAKE256 'hash' of the message.
> 
> Copy-and-paste error in the help message: 87 -> 44.
> ...
> Similarly here: 87 -> 65.

Fixed.

> Should all MODULE_SIG_KEY_TYPE_ML_DSA_* options depend on
> MODULE_SIG_SHAKE256 to match the updated
> Documentation/admin-guide/module-signing.rst?
> 
> Similarly, do MODULE_SIG_KEY_TYPE_RSA and MODULE_SIG_KEY_TYPE_ECDSA
> require any "depends on" update with respect to the addition of
> MODULE_SIG_SHAKE256?

Um.  In theory ML-DSA can use hashes other than SHAKE256, but I'm not sure
that OIDs exist yet to indicate that.  Also, I'm not sure how to implement the
crypto API interface such that you can ask for, say, "ml-dsa87(sha512)" from
crypto_sig.

Anyway, for the moment, I'm going to post a v7 as I've made some substantial
cleanups.

David