public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Simo Sorce <simo@redhat.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, 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,  linux-crypto@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	 linux-kernel@vger.kernel.org
Subject: Re: Module signing and post-quantum crypto public key algorithms
Date: Mon, 16 Jun 2025 11:14:46 -0400	[thread overview]
Message-ID: <69775877d04b8ee9f072adfd2c595187997e59fb.camel@HansenPartnership.com> (raw)
In-Reply-To: <7ad6d5f61d6cd602241966476252599800c6a304.camel@redhat.com>

On Mon, 2025-06-16 at 10:02 -0400, Simo Sorce wrote:
> On Fri, 2025-06-13 at 13:50 -0400, James Bottomley wrote:
> > I agree it's coming, but there's currently no date for post quantum
> > requirement in FIPS, which is the main driver for this.
> 
> The driver is the CNSA 2.0 document which has precise deadlines, not
> FIPS.

The NSA "hopes" that the CNSA algorithms will be in FIPS by about 2030,
yes.  However, even if you have CNSA 2.0 requirement, it still includes
several classical algorithms (it even includes RSA3072 which is, to say
the least, a bit controversial).

>  That said ML-KEM and ML-DSA can already be validated, so FIPS is
> also covered.

The main worry everyone has is that while it is believed that there's
not a quantum short cut over classical for lattice algorithms, they
haven't been studied long enough to believe there's no classical short
cut to breaking the encryption.  The only real algorithms we're sure
about are the hash based ones, so perhaps we should start with XMSS/LMS
before leaping to ML-.  Particularly for kernel uses like modules, the
finite signatures problem shouldn't be that limiting.

> > Current estimates say Shor's algorithm in "reasonable[1]" time
> > requires around a million qubits to break RSA2048, so we're still
> > several orders of magnitude off that.
> 
> Note that you are citing sources that identify needed physical qbits
> for error correction, but what IBM publishes is a roadmap for *error
> corrected* logical qbits. If they can pull that off that computer
> will already be way too uncomfortably close (you need 2n+3 error
> corrected logical qbits to break RSA).

The roadmap is based on a linear presumption of physical to logical
qbit scaling.  Since quantum error effects are usually exponential in
nature that seems optimistic ... but, hey, we should know in a couple
of years.

> > Grover's only requires just over 2,000 (which
> > is why NIST is worried about that first).
> 
> Grover can at most half the search space,

I assume you're thinking in terms of 2^n spaces, because for a search
space of size s, classical brute force takes O(s) and quantum takes
O(sqrt(s)).  So if s=2^n then quantum takes O(2^(n/2)).  Which is why
the recommendation is to double the bits of security.

>  so it is not really a concern, even with the smallest key sizes the
> search space is still 2^64 ... so it makes little sense to spend a
> lot of engineering time to find all places where doubling key size
> break things and then do a micro-migration to that. It is better to
> focus the scarce resources on the long term.

Well the CNSA 2.0 doc you cite above hedges and does a 1.5x security
bit increase, so even following it we can't do P-256, 25519 or RSA2048
we have to move to at least P-384 and X448 (even though it allows
RSA3072, I don't think we should be supporting that).  So if we're
going to have to increase key size anyway, we may as well up it to 256
bits of security.

So even if you believe quantum is slightly more imminent than the
Kazakh Gerbil invasion, we should still begin with the key size
increase.

Regards,

James


  reply	other threads:[~2025-06-16 15:14 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 [this message]
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)
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=69775877d04b8ee9f072adfd2c595187997e59fb.camel@HansenPartnership.com \
    --to=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