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: <IA4PR84MB4011FE5ABA934DEF08F1A263ABC3A@IA4PR84MB4011.NAMPRD84.PROD.OUTLOOK.COM>
Date: Fri, 7 Nov 2025 23:10:25 +0000
From: "Elliott, Robert (Servers)" <elliott@....com>
To: Simo Sorce <simo@...hat.com>,
        James Bottomley
	<James.Bottomley@...senPartnership.com>,
        Ignat Korchagin
	<ignat@...udflare.com>,
        David Howells <dhowells@...hat.com>
CC: 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: Simo Sorce <simo@...hat.com>
> Sent: Monday, June 16, 2025 12:27 PM
> Subject: Re: Module signing and post-quantum crypto public key
> algorithms
> 
...
> Of course we can decide to hedge *all bets* and move to a composed
> signature (both a classic and a PQ one), in which case I would suggest
> looking into signatures that use ML-DSA-87 + Ed448 or ML-DSA-87 + P-521
> ,ideally disjoint, with a kernel policy that can decide which (or both)
> needs to be valid/checked so that the policy can be changed quickly via
> configuration if any of the signature is broken.
> 
> This will allow for fears of Lattice not being vetted enough to be
> managed as well as increasing the strength of the classic option, while
> maintaining key and signature sizes manageable.

I like the ML-DSA-87 + Ed448 combination.

Consider signing with two signatures: traditional and composite.

The traditional signature would use whatever algorithm is used today.
Legacy verifiers would only check that.

The composite signature would use:
    ML-DSA-87 + Ed448 (+ SHAKE256 if using the CMS composite construction)

New verifiers would only check the composite signature (which requires
checking both of its parts).

That composite would be
* FIPS compliant (all the algorithms are)
* CNSA compliant (ML-DSA-87 makes it so; the rest is just noise)
* compliant with any European requirements or preferences for using hybrids
* compliant with any requirements or preferences for high security strengths
* even with two algorithms, faster than the traditional choices for signing,
  and faster than ECDSA but slower than RSASSA for verification. By bringing
  in Ed448, it might be viewed as an improvement even by PQC skeptics.

It'd be nice if signed kernel modules and packages used the same 
algorithms. Both of these define ML-DSA-87 + Ed448 composites:
* draft-ietf-lamps-pq-composite-sigs
  * id-MLDSA87-Ed448-SHAKE256 with OID: 1.3.6.1.5.5.7.6.51
* draft-ietf-openpgp-pqc
  * ML-DSA-87+Ed448 as public key algorithm ID 31