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] [day] [month] [year] [list]

Message-ID: <IA4PR84MB4011485C0EFFFF9F2820A1BFABC1A@IA4PR84MB4011.NAMPRD84.PROD.OUTLOOK.COM>
Date: Sun, 9 Nov 2025 19:30:07 +0000
From: "Elliott, Robert (Servers)" <elliott@....com>
To: David Howells <dhowells@...hat.com>
CC: Simo Sorce <simo@...hat.com>,
        James Bottomley
	<James.Bottomley@...senPartnership.com>,
        Ignat Korchagin
	<ignat@...udflare.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "Stephan
 Mueller" <smueller@...onox.de>,
        "torvalds@...ux-foundation.org"
	<torvalds@...ux-foundation.org>,
        Paul Moore <paul@...l-moore.com>, "Lukas
 Wunner" <lukas@...ner.de>,
        Clemens Lang <cllang@...hat.com>,
        David Bohannon
	<dbohanno@...hat.com>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-security-module@...r.kernel.org"
	<linux-security-module@...r.kernel.org>,
        "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: Module signing and post-quantum crypto public key algorithms



> -----Original Message-----
> From: David Howells <dhowells@...hat.com>
> Sent: Saturday, November 8, 2025 1:47 AM
> To: Elliott, Robert (Servers) <elliott@....com>
> Cc: dhowells@...hat.com; Simo Sorce <simo@...hat.com>; James Bottomley
> <James.Bottomley@...senPartnership.com>; Ignat Korchagin
> <ignat@...udflare.com>; Herbert Xu <herbert@...dor.apana.org.au>;
> Stephan Mueller <smueller@...onox.de>; torvalds@...ux-foundation.org;
> Paul Moore <paul@...l-moore.com>; Lukas Wunner <lukas@...ner.de>;
> 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
> 
> Elliott, Robert (Servers) <elliott@....com> wrote:
> 
> > The traditional signature would use whatever algorithm is used today.
> > Legacy verifiers would only check that.
> 
> Would there be any legacy verifiers?  Kernel modules are generally tied
> to the kernel version for which they were compiled.  Granted there are
> things like the wifi regulatory stuff that are also signed.

If the system building and signing a module doesn't have OpenSSL 3.5 yet,
it can only provide a legacy signature. If the kernel is only looking
for a composite by default, a kernel command line allowing a legacy
signature to be accepted would help the transition.

Userspace tools can check signatures, but I don't know if that is done
in any non-developer situations. I did it manually while testing x86
optimized crypto module changes a few years ago.

If and when a distro is confident there are no userspace tools, it could
stop signing with legacy signatures.

> But note also, PKCS#7 supports multiple independent signatures in a
> single object.  The kernel will handle this already.  At least one
> signature must be verifiable and none must be blacklisted.

Yes, I think that makes multiple signatures viable.

> I assume that the main aim of using a composite algorithm is to share
> the result of the content hash - but in this case only the
> authenticatedAttributes are going to be hashed for the signature, and
> that's relatively small.

The composite motivation is to provide some protection if someone
discovers a basic flaw in the PQC algorithm. If quantum computers
haven't arrived yet to break the traditional algorithm, the
composite still proves validity.

The CMS and OpenPGP constructions ensure that the signatures are
non-separable; an attacker cannot strip off the strong one and leave
the broken one. The verifier always runs both algorithms (unlike
the current OR policy with multiple signatures).