Remix.run Logo
Cloudflare targets 2029 for full post-quantum security(blog.cloudflare.com)
201 points by ilreb 6 hours ago | 67 comments
rdl 4 hours ago | parent | next [-]

It will be interesting to compare PQ rollout to HTTPS rollout historically (either the "SSL becomes widespread in 2015" thing, or the deprecation SSL 3.0). Cloudflare is in an easy position to do stuff like this because it can decouple end user/browser upgrade cycles from backend upgrade cycles.

Some browsers and some end user devices get upgraded quickly, so making it easy to make it optionally-PQ on any site, and then as that rollout extends, some specialty sites can make it mandatory, and then browser/device UX can do soft warnings to users (or other activity like downranking), and then at some point something like STS Strict can be exposed, and then largely become a default (and maybe just remove the non-PQ algorithms entirely from many sites).

I definitely was on team "the risks of a rushed upgrade might outweigh the risks of actual quantum breaks" until pretty recently -- rushing to upgrade has lots of problems always and is a great way to introduce new bugs, but based on the latest information, the balance seems to have shifted to doing an upgrade quickly.

Updating websites is going to be so much easier than dealing with other systems (bitcoin probably the worst; data at rest storage systems; hardware).

jeroenhd 4 hours ago | parent | next [-]

If any kind of proof about serious quantum computers comes to light, browsers can force most websites' hand by marking non-PQ ciphers as insecure.

Maybe it'll require TLS 1.4/QUIC 2, with no changes but the cipher specifications, but it can happen in two or three years. Certificates themselves don't last longer than a year anyway. Corporations running ancient software that doesn't support PQ TLS will have the same configuration options to ignore the security warnings already present for TLS 1.0/plain HTTP connections.

The biggest problem I can imagine is devices talking to the internet no longer receiving firmware updates. If the web host switches protocols, the old clients will start dying off en masses.

bwesterb 4 hours ago | parent | next [-]

No need for a TLS 1.4.

Leaf certificates don't last long, but root CAs do. An attacker can just mint new certs from a broken root key.

Hopefully many devices can be upgraded to PQ security with a firmware update. Worse than not receiving updates, is receiving malicious firmware updates, which you can't really prevent without upgrading to something safe first.

PunchyHamster 2 hours ago | parent | prev [-]

There is no reason to not support non quantum safe algorithms for foreseeable future in the first place

bwesterb 4 hours ago | parent | prev | next [-]

Waiting now means rushing even more close to the deadline! We added stats on origin support for post-quantum encryption. Not as much support as browsers of course, but better than I expected. Still a long road (and authentication!). https://radar.cloudflare.com/post-quantum

stingraycharles 4 hours ago | parent | prev [-]

> Updating websites is going to be so much easier than dealing with other systems (bitcoin probably the worst; data at rest storage systems; hardware).

IPv6 deserves a prominent spot there

hackerman70000 4 hours ago | parent | prev | next [-]

Cloudflare pushing PQ by default is probably the single most impactful thing that can happen for adotpion. Most developers will never voluntarily migrate their TLS config. Making it the default at the CDN layer means millions of sites get upgraded without anyone making a decision

jgrahamc 4 hours ago | parent [-]

Cloudflare has long been doing work on PQ (sometimes in conjunction with Google) and rolled out PQ encryption for our customers. You can read about where this all started for us 7 years back: https://blog.cloudflare.com/towards-post-quantum-cryptograph... and four years ago rolled out PQ encryption for all customers: https://blog.cloudflare.com/post-quantum-for-all/

The big change here is that we're going to roll out PQ authentication as well.

One important decision was to make this "included at no extra cost" with every plan. The last thing the Internet needs is blood-sucking parasites charging extra for this.

cetinsert 4 hours ago | parent | prev | next [-]

You can do PQ queries with us at qi.rt.ht!

Which one do you think is PQ-secure?

https://qi.rt.ht/?pq={api.,}{stripe,paypal}.com

1a527dd5 3 hours ago | parent [-]

That is a beautiful api.

MrRadar 2 hours ago | parent | prev | next [-]

Along similar lines, Mozilla recently updated their recommended server-side TLS configuration to enable the X25519MLKEM768 post-quantum key exchange now that it's making it into actually-deployed software versions: https://wiki.mozilla.org/Security/Server_Side_TLS At the same time they removed their "old client" compatibility profile as newer TLS libraries do not implement the necessary algorithms (or at least do not enable them by default) and slightly tweaked the "intermediate" compatibility profile to remove a fallback necessary for IE 11 on Windows 7 (now Windows 10 is the minimum compatible version for that profile).

lexlambda 2 hours ago | parent | prev | next [-]

> news.ycombinator.com:443 is using X25519, which is not post-quantum secure.

This is the result of Cloudflare's test "Check if a host supports post-quantum TLS key exchange" offered on https://radar.cloudflare.com/post-quantum.

Hoping there is already a migration plan. Fortunately many modern tools make it easy to switch to PQ, maybe someone knows which stack HN is running and if it would be possible.

Bender 4 hours ago | parent | prev | next [-]

Is this still theory or are there working Quantum systems that have broken anything yet?

tptacek 3 hours ago | parent | next [-]

Among cryptography engineers there was a sharp vibe shift over the last 2 months; there are papers supporting that vibe shift, but there's also a rumor mill behind it too. The field has basically aligned fully in a way it hadn't before that this is an urgent concern. The simplest way to put it is that everyone's timeline for a real-world CRQC has shortened. Not everyone has the same timeline, but all those timelines are now shorter, and for some important (based on industry and academic position) practitioners, it's down to "imminent".

xienze 2 hours ago | parent [-]

> The field has basically aligned fully in a way it hadn't before that this is an urgent concern.

AKA “we want more funding.”

dralley 26 minutes ago | parent [-]

There's a simultaneous push coming from the government to support PQC, ASAP, so it's not just researchers pushing this.

OkayPhysicist 4 hours ago | parent | prev | next [-]

It's theory. The concern is for avoiding a (likely, IMO) scenario where the only real indication that someone cracked QC is one or more teams of researchers in the field going dark because they got pulled into some tight-lipped NSA project. If we wait until we have an unambiguous path to QC, it might well be too late.

To avoid the scenario where for a prolonged period of time the intelligence community has secret access to QC, researchers against that type of thing are incentivized to shout fire when they see the glimmerings of a possibly productive path of research.

rectang 2 hours ago | parent [-]

> one or more teams of researchers in the field going dark

If the intelligence community is going to nab the first team that has a quantum computing breakthrough, does it actually help the public to speed up research?

It seems like an arms race the public is destined to lose because the winning team will be subsumed no matter what.

evil-olive 3 hours ago | parent | prev | next [-]

still theory, but there seems to be an emerging consensus that quantum systems capable of real-world attacks are closer to fruition than most people generally assumed.

Filippo Valsorda (maintainer of Golang's crypto packages, among other things) published a summary yesterday [0] targeted at relative laypeople, with the same "we need to target 2029" bottom line.

0: https://words.filippo.io/crqc-timeline/

PUSH_AX 4 hours ago | parent | prev | next [-]

Nothing has been broken yet, however data can be collected now and be cracked when the time comes, hence why there is a push.

thenewnewguy 2 hours ago | parent | next [-]

Can a theoretical strong enough quantum computer break PFS?

wahern an hour ago | parent [-]

QC breaks perfect forward secrecy schemes using non-PQC algorithms, same as for non-PFS. PFS schemes typically use single-use ephemeral DH/ECDH key pairs for symmetric key exchange, separate from the long-term signing keys for authentication.

ankit_mishra 3 hours ago | parent | prev [-]

[dead]

moi2388 4 hours ago | parent | prev [-]

Theory. And afaik there are still questions as to if the PQ algorithms are actually secure.

tptacek 3 hours ago | parent | next [-]

There are not in fact meaningful questions about whether the settled-on PQC constructions are secure, in the sense of "within the bounds of our current understanding of QC".

ls612 3 hours ago | parent [-]

Didn't one of the PQC candidates get found to have a fatal classical vulnerability? Are we confident we won't find any future oopsies like that with the current PQC candidates?

tptacek 3 hours ago | parent | next [-]

The whole point of the competition is to see if anybody can cryptanalyze the contestants. I think part of what's happening here is that people have put all PQC constructions in bucket, as if they shared an underlying technology or theory, so that a break in one calls all of them into question. That is in fact not at all the case. PQC is not a "kind" of cryptography. It's a functional attribute of many different kinds of cryptography.

The algorithm everyone tends to be thinking of when they bring this up has literally nothing to do with any cryptography used anywhere ever; it was wildly novel, and it was interesting only because it (1) had really nice ergonomics and (2) failed spectacularly.

cwillu 3 hours ago | parent | prev [-]

It's the same situation with classical encryption. It's not uncommon for a candidate algorithm [to be discovered ] to be broken during the selection process.

sophacles 4 hours ago | parent | prev [-]

tbf - since we still don't know if p != np, there are still questions about if the current algorithms are secure also.

moi2388 4 hours ago | parent [-]

Fair, but recently several PQ algorithms have been shown to in fact not be secure, with known attacks, so I wouldn’t equate them

tptacek 3 hours ago | parent | next [-]

Which PQ algorithms would you be referring to here?

nick238 an hour ago | parent [-]

https://en.wikipedia.org/wiki/NIST_Post-Quantum_Cryptography... and search for "published attacks".

tptacek 29 minutes ago | parent [-]

Why don't you go ahead and pick out the attacks in here that you think are relevant to this conversation? It can't be on me to do that, because obviously my subtext is that none of them are.

sophacles 3 hours ago | parent | prev [-]

Interesting. I'd like to learn more about this - where can I find info about it?

tombert 2 hours ago | parent | prev | next [-]

Outside of the PQ algorithms not being as thoroughly vetted as others, is there any negatives to shifting algorithms? Like even if someone were to prove that quantum computing is a dud, is there any reason why we shouldn't be using this stuff anyway?

MrRadar an hour ago | parent [-]

Post-quantum algorithms tend to be slower than existing elliptic curve algorithms and require more data to be exchanged to provide equivalent security against attacks run on non-quantum computers.

tombert 31 minutes ago | parent [-]

Any idea how much slower? Like are we talking half the speed? A quarter? 1%?

Sorry, I'm just very out of the loop on some of this stuff and I'm trying to play a game of catchup.

MrRadar 8 minutes ago | parent [-]

This page lists some figures for ML-KEM-768 (which is the PQ key exchange algorithm that's most widely deployed today): https://blog.cloudflare.com/pq-2025/#ml-kem-versus-x25519 This one is actually faster than X25519 (a highly optimized ECC algorithm) by about double but requires 1,184 bytes of data to be exchanged per keyshare vs 32 for X25519. In practice everyone today is using a hybrid algorithm (where you do both ECC and PQ in case the PQ algorithm has an undiscovered weakness) so an ECC+PQ key share will be strictly slower than an ECC-only keyshare.

This page lists some numbers for different PQ signature algorithms: https://blog.cloudflare.com/another-look-at-pq-signatures/#t... Right now the NIST has selected three different ones (ML-DSA, SLH-DSA, and Falcon a.k.a. FN-DSA) which each have different trade-offs.

SLH-DSA is slow and requires a large amount of data for signatures, however it's considered the most secure of the algorithms (since it's based on the well-understood security properties of symmetric hash algorithms) so it was selected primarily as a "backup" in case the other two algorithms are both broken (which may be possible as they're both based on the same mathematical structure).

ML-DSA and Falcon are both fairly fast (within an order of magnitude of Ed25519, the X25519 curve signature algorithm), but both require significantly larger keys (41x/28x) and signatures (38x/10x) compared to Ed25519. Falcon has the additional constraint that achieving the listed performance in that table requires a hardware FPU that implements IEEE-754 with constant-time double-precision math. CPUs that do not have such an FPU will need to fall back to software emulation of the required floating point math (most phone, desktop, and server CPUs have such an FPU but many embedded CPUs and microcontrollers do not).

The net result is that TLS handshakes with PQ signatures and key exchange may balloon to high single- or double-digit kilobytes in size, which will be especially impactful for users on marginal connections (and may break some "middle boxes" https://blog.cloudflare.com/nist-post-quantum-surprise/#dili...).

valeriozen 4 hours ago | parent | prev | next [-]

cloudflare making pq the default is the only way we get real adoption. most devs are never going to mess with their tls settings unless they absolutely have to. having it happen at the cdn level is the perfect silent upgrade for millions of sites without the owners needing to do anything

diarrhea 3 hours ago | parent [-]

https://news.ycombinator.com/item?id=47677483

coldpie 3 hours ago | parent [-]

I noticed this, too. valeriozen, can you explain what happened here?

Context, two nearly identical comments from different users.

hackerman70000 at 16:09 https://news.ycombinator.com/item?id=47677483 :

> Cloudflare pushing PQ by default is probably the single most impactful thing that can happen for adotpion. Most developers will never voluntarily migrate their TLS config. Making it the default at the CDN layer means millions of sites get upgraded without anyone making a decision

valeriozen at 16:17 https://news.ycombinator.com/item?id=47677615 :

> cloudflare making pq the default is the only way we get real adoption. most devs are never going to mess with their tls settings unless they absolutely have to. having it happen at the cdn level is the perfect silent upgrade for millions of sites without the owners needing to do anything

wmf an hour ago | parent [-]

They're using the same AI model?

ossianericson an hour ago | parent | prev | next [-]

The CDN part is the easy half. In my work the harder problem has most often been internal service mesh, mTLS between services, any infra that doesn’t terminate at a CDN. Has a bad habit of longer certificate lifetimes and older TLS stacks, and nobody is upgrading it for you.

20k 4 hours ago | parent | prev | next [-]

Quantum computing, and the generic term 'quantum' is gearing up to be the next speculative investment hype bubble after AI, so prepare for a lot of these kinds of articles

Hasz 4 hours ago | parent | next [-]

nah. governments around the world are hoovering up traffic today with the hope of a "cheap" (by nation state standards) quantum computer. Some of the secrets sent today are "evergreen" (i.e are still relevant 10+ years into the future), amongst a whole lot of cruft. There is massive incentive to hide the technology to keep your peers transmitting in vulnerable encryption as long as possible.

nickspacek 4 hours ago | parent [-]

For sure, that or just ensuring they have laws in place that grant them access to the unencrypted data we are sending to CDNs operating in their jurisdiction (when necessary for national security reasons).

bwesterb 4 hours ago | parent | prev [-]

At least it's time bound: hope to have this job done by 2029!

Sattyamjjain 2 hours ago | parent | prev | next [-]

[dead]

heliumtera 5 hours ago | parent | prev | next [-]

And that changes what?

bwesterb 4 hours ago | parent | next [-]

If we do our job, it changes nothing. Problem with security generally: no spectacle if it's all correct. :)

ljhsiung 2 hours ago | parent | prev | next [-]

"Nothing happened for y2k" energy

ezfe 4 hours ago | parent | prev [-]

It would mean that they're future-proofing their security

ls612 5 hours ago | parent | prev [-]

The secrecy around this is precisely the opposite of what we saw in the 90s when it started to become clear DES needed to go. Yet another sign that the global powers are preparing for war.

tptacek 5 hours ago | parent | next [-]

What do you mean? For as long as I remember (back to late 1994) people understood DES to be inadequate; we used DES-EDE and IDEA (and later RC4) instead. What "secrecy" would there have been? The feasibility of breaking DES given a plausible budget goes all the way back to the late 1970s. The first prize given for demonstrating a DES break was only $10,000.

adrian_b 4 hours ago | parent | next [-]

Triple-key DES (DES-EDE) had already been proposed by IBM in 1979, in response to the criticism that the 56-bit keys of DES are far too short.

So practically immediately after DES was standardized, people realized that NSA had crippled it by limiting the key length to 56 bits, and they started to use workarounds.

Before introducing RC2 and RC4 in 1987, Ronald Rivest had used since 1984 another method of extending the key length of DES, named DESX, which was cheaper than DES-EDE as it used a single block cipher function invocation. However, like also RC4, DESX was kept as a RSA trade secret, until it was leaked, also like RC4, during the mid nineties.

IDEA (1992, after a preliminary version was published in 1991) was the first block cipher function that was more secure than DES and which was also publicly described.

ls612 3 hours ago | parent | prev [-]

People were willing to explicitly explain why it was inadequate rather than keep it secret. That is the difference.

tptacek 3 hours ago | parent [-]

What was to explain? It had a 56-bit key.

ls612 an hour ago | parent [-]

Was that the only thing wrong with it? The 90s was definitely before my time but I was under the impression reading about it that there were also fundamental flaws with DES which lead to the competition which ultimately produced AES.

tptacek 29 minutes ago | parent [-]

Yes, that was what was wrong with DES. I mean, it also had an 8-byte block size, which turns out to be inadequate as well, but that's true of IDEA and Blowfish as well.

NitpickLawyer 5 hours ago | parent | prev [-]

My read of the recent google blog post is that they framed it as cryptocurrency related stuff just so they don't say the silent thing out loud. But lots of people "in the know" / working on this are taking it much more seriously than just cryptobros go broke. So my hunch is that there's more to it and they didn't want to say it / couldn't / weren't allowed to.

adrian_b 4 hours ago | parent | next [-]

It should be noted that quantum computers are a threat mainly for interactions between unrelated parties which perform legal activities, e.g. online shopping, online banking, notarized legal documents that use long-term digital signatures.

Quantum computers are not a threat for spies or for communications within private organizations where security is considered very important, where the use of public-key cryptography can easily be completely avoided and authentication and session key exchanges can be handled with pre-shared secret keys used only for that purpose.

dadrian 2 hours ago | parent | prev | next [-]

I will bring this up at the next meeting of the secret cryptographer cabal where we decide what information to reveal to non-cryptographers.

IncreasePosts 5 hours ago | parent | prev [-]

What is "it" that you're referring to?

wil421 4 hours ago | parent [-]

> mitigating harvest-now/decrypt-later attacks.

Most likely the NSA or someone else is ahead of the game and already has a quantum computer. If the tech news rumors are to true the NSA has a facility in Utah that can gather large swaths of the internet and process the data.

bookofjoe 2 hours ago | parent [-]

This?: https://nsa.gov1.info/utah-data-center/

tonfa 2 hours ago | parent [-]

FYI this is a parody website. (in case it's not obvious)

bookofjoe 8 minutes ago | parent [-]

It wasn't obvious to me!