linux-kernel - Re: Module signing and post-quantum crypto public key algorithms

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: <20250613170456.GA1284@sol>
Date: Fri, 13 Jun 2025 10:04:56 -0700
From: Eric Biggers <ebiggers@...nel.org>
To: David Howells <dhowells@...hat.com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>,
	Stephan Mueller <smueller@...onox.de>, Simo Sorce <simo@...hat.com>,
	torvalds@...ux-foundation.org, Paul Moore <paul@...l-moore.com>,
	Lukas Wunner <lukas@...ner.de>,
	Ignat Korchagin <ignat@...udflare.com>,
	Clemens Lang <cllang@...hat.com>,
	David Bohannon <dbohanno@...hat.com>,
	Roberto Sassu <roberto.sassu@...wei.com>, keyrings@...r.kernel.org,
	linux-crypto@...r.kernel.org, linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: Module signing and post-quantum crypto public key algorithms

On Fri, Jun 13, 2025 at 03:54:30PM +0100, David Howells wrote:
> Hi,
> 
> So we need to do something about the impending quantum-related obsolescence of
> the RSA signatures that we use for module signing, kexec, BPF signing, IMA and
> a bunch of other things.
> 
> From my point of view, the simplest way would be to implement key verification
> in the kernel for one (or more) of the available post-quantum algorithms (of
> which there are at least three), driving this with appropriate changes to the
> X.509 certificate to indicate that's what we want to use.
> 
> The good news is that Stephan Mueller has an implemementation that includes
> kernel bits that we can use, or, at least, adapt:
> 
> 	https://github.com/smuellerDD/leancrypto/
> 
> Note that we only need the signature verification bits.  One question, though:
> he's done it as a standalone "leancrypto" module, not integrated into crypto/,
> but should it be integrated into crypto/ or is the standalone fine?

The proper place for crypto algorithm implementations, both new and existing, is
lib/crypto/.  crypto/ should contain only the compatibility code to integrate
the algorithm implementations into the generic APIs like crypto_akcipher, *if*
it's needed.

ML-DSA a.k.a. Dilithium support is fairly low on my priority list at the moment,
so if someone really wants it soon they would need to drive that effort.

- Eric