public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: "Elliott, Robert (Servers)" <elliott@hpe.com>
To: Simo Sorce <simo@redhat.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Ignat Korchagin <ignat@cloudflare.com>,
	David Howells <dhowells@redhat.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	Stephan Mueller <smueller@chronox.de>,
	"torvalds@linux-foundation.org" <torvalds@linux-foundation.org>,
	Paul Moore <paul@paul-moore.com>,
	"Lukas Wunner" <lukas@wunner.de>,
	Clemens Lang <cllang@redhat.com>,
	David Bohannon <dbohanno@redhat.com>,
	Roberto Sassu <roberto.sassu@huawei.com>,
	"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-security-module@vger.kernel.org"
	<linux-security-module@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: Module signing and post-quantum crypto public key algorithms
Date: Fri, 7 Nov 2025 23:10:25 +0000	[thread overview]
Message-ID: <IA4PR84MB4011FE5ABA934DEF08F1A263ABC3A@IA4PR84MB4011.NAMPRD84.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <3d650cc9ff07462e5c55cc3d9c0da72a3f2c5df2.camel@redhat.com>



> -----Original Message-----
> From: Simo Sorce <simo@redhat.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



  parent reply	other threads:[~2025-11-07 23:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-13 14:54 Module signing and post-quantum crypto public key algorithms David Howells
2025-06-13 15:21 ` Ignat Korchagin
2025-06-13 15:42   ` David Howells
2025-06-13 17:33   ` Simo Sorce
2025-06-13 17:50     ` James Bottomley
2025-06-13 17:55       ` Stephan Mueller
2025-06-16 14:02       ` Simo Sorce
2025-06-16 15:14         ` James Bottomley
2025-06-16 17:27           ` Simo Sorce
2025-06-19 18:49             ` Stefan Berger
2025-11-07 10:03               ` David Howells
2025-11-07 10:23                 ` Stephan Mueller
2025-11-07 19:19                 ` Stefan Berger
2025-11-07 23:10             ` Elliott, Robert (Servers) [this message]
2025-11-08  7:46               ` David Howells
2025-11-09 19:30                 ` Elliott, Robert (Servers)
2025-11-11 16:14                   ` Simo Sorce
2025-11-11 18:38                     ` David Howells
2025-06-13 15:43 ` Linus Torvalds
2025-06-13 16:13 ` James Bottomley
2025-06-13 16:32   ` Roberto Sassu
2025-06-13 16:34   ` Stephan Mueller
2025-06-13 17:04 ` Eric Biggers
2025-06-19 12:31 ` Lukas Wunner
2025-06-19 23:22   ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=IA4PR84MB4011FE5ABA934DEF08F1A263ABC3A@IA4PR84MB4011.NAMPRD84.PROD.OUTLOOK.COM \
    --to=elliott@hpe.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=cllang@redhat.com \
    --cc=dbohanno@redhat.com \
    --cc=dhowells@redhat.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=ignat@cloudflare.com \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lukas@wunner.de \
    --cc=paul@paul-moore.com \
    --cc=roberto.sassu@huawei.com \
    --cc=simo@redhat.com \
    --cc=smueller@chronox.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox