[HN Gopher] Cloudflare targets 2029 for full post-quantum security
___________________________________________________________________
Cloudflare targets 2029 for full post-quantum security
Author : ilreb
Score : 250 points
Date : 2026-04-07 14:07 UTC (8 hours ago)
(HTM) web link (blog.cloudflare.com)
(TXT) w3m dump (blog.cloudflare.com)
| ls612 wrote:
| 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.
| NitpickLawyer wrote:
| 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.
| IncreasePosts wrote:
| What is "it" that you're referring to?
| wil421 wrote:
| > 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 wrote:
| This?: https://nsa.gov1.info/utah-data-center/
| tonfa wrote:
| FYI this is a parody website. (in case it's not obvious)
| bookofjoe wrote:
| It wasn't obvious to me!
| adrian_b wrote:
| 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 wrote:
| I will bring this up at the next meeting of the secret
| cryptographer cabal where we decide what information to
| reveal to non-cryptographers.
| tptacek wrote:
| 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 wrote:
| 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 wrote:
| People were willing to explicitly explain why it was
| inadequate rather than keep it secret. That is the
| difference.
| tptacek wrote:
| What was to explain? It had a 56-bit key.
| ls612 wrote:
| 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 wrote:
| 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.
| heliumtera wrote:
| And that changes what?
| ezfe wrote:
| It would mean that they're future-proofing their security
| bwesterb wrote:
| If we do our job, it changes nothing. Problem with security
| generally: no spectacle if it's all correct. :)
| ljhsiung wrote:
| "Nothing happened for y2k" energy
| Bender wrote:
| Is this still theory or are there working Quantum systems that
| have broken anything yet?
| moi2388 wrote:
| Theory. And afaik there are still questions as to if the PQ
| algorithms are actually secure.
| sophacles wrote:
| tbf - since we still don't know if p != np, there are still
| questions about if the current algorithms are secure also.
| moi2388 wrote:
| Fair, but recently several PQ algorithms have been shown to
| in fact not be secure, with known attacks, so I wouldn't
| equate them
| sophacles wrote:
| Interesting. I'd like to learn more about this - where
| can I find info about it?
| mswphd wrote:
| they're almost assuredly talking about two things (maybe
| 3 if they _really_ know what they 're talking about, but
| the third is something that people making this argument
| like to pretend doesn't exist).
|
| 1. the main "eye catching" attack was the [attack on
| SIDH](https://eprint.iacr.org/2022/975.pdf). it was very
| much a "thought to be entirely secure" to "broken in 5
| minutes with a Sage (python variant) implementation"
| within ~1 week. Degradation from "thought to be (sub-)exp
| time" to "poly time". very bad.
|
| 2. the other main other "big break" was the [RAINBOW
| attack](https://eprint.iacr.org/2022/214.pdf). this was a
| big attack, but it did not break all parameter sets, e.g.
| it didn't suddenly reduce a problem from exp-time to
| poly-time. instead, it was a (large) speedup for existing
| attacks.
|
| anyway, someone popular among some people in tech (the
| cryptographer Dan Bernstein) has been trying
| (successfully) to slow the PQC transition for ~10 years.
| His strategy throughout has been complaining that a very
| particular class of scheme ("structured LWE-based
| schemes") are suspect. He has had several complaints that
| have shifted throughout the years (galois automorphism
| structure for a while, then whatever his "spherical
| models" stuff was lmao). There have been no appreciable
| better attacks (nothing like the above) on them since
| then. But he still complains, saying that instead people
| should use
|
| 1. NTRU, a separate structured lattice scheme (that he
| coincidentally submitted a scheme for standardization
| with). Incidentally, it had [a very bad
| attack](https://eprint.iacr.org/2016/127) ~ 2016. Didn't
| kill PQC, but killed a broad class of other schemes
| (NTRU-based fully homomorphic encryption, at least using
| tensor-based multiplication)
|
| 2. McCliece, a scheme from the late 70s (that has
| horrendously large public keys --- people avoid it for a
| reason). He also submitted a version of this for
| standardization. It also had a [greatly improved attack
| recently](https://eprint.iacr.org/2024/1193).
|
| Of course, none of those are relevant to improved attacks
| on the math behind ML-KEM (algebraically structured
| variants on ring LWE). there have been _some_ progress on
| these, but not really. It 's really just "shaving bits",
| e.g. going from 2^140 to 2^135 type things. The rainbow
| attack (of the first two, the "mild" one) reduced things
| by a factor ~2^50, which is clearly unacceptable.
|
| Unfortunately, because adherents of Dan Bernstein will
| pop up, and start saying a bunch of stuff confidently
| that is much too annoying to refute, as they have no clue
| what the actual conversation is. So the conversation
| becomes
|
| 1. people who know things, who tend to not bother saying
| anything (with rare exceptions), and 2. people who parrot
| Dan's (very wrong at this point honestly, but they've
| shifted over time, so it's more of 'wrong' and 'unwilling
| to admit it was wrong') opinions.
|
| the dynamic is similar to how when discussions of
| vaccines on the internet occur, many medical
| professionals may not bother engaging, so you'll get a
| bunch of insane anti-vax conspiracies spread.
| tptacek wrote:
| For whatever it's worth I think I cosign all of this.
| tptacek wrote:
| Which PQ algorithms would you be referring to here?
| nick238 wrote:
| https://en.wikipedia.org/wiki/NIST_Post-
| Quantum_Cryptography... and search for "published
| attacks".
| tptacek wrote:
| 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.
| tptacek wrote:
| 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 wrote:
| 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?
| cwillu wrote:
| 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.
| tptacek wrote:
| 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.
| ls612 wrote:
| Yeah I get that, what I am really asking is that I know
| in my field, I can quickly get a vibe as to whether
| certain new work is good or not so good, and where any
| bugaboos are likely to be. For those who know PQC like I
| know economics, do they believe at this point that the
| algorithms have been analyzed successfully to a level
| comparable to DH or RSA? Or is this really gonna be a
| rush job under the gun because we have no choice?
| tptacek wrote:
| Lattice cryptography was a contender alongside curves as
| a successor to RSA. It's not new. The specific lattice
| constructions we looked at during NIST PQC were new
| iterations on it, but so was Curve25519 when it was
| introduced. It's _extremely not_ a rush job.
|
| The elephant in the room in these conversations is Daniel
| Bernstein and the shade he has been casting on MLKEM for
| the last few years. The things I think you should
| remember about that particular elephant are (1) that he's
| cited SIDH as a reason to be suspicious of MLKEM, which
| indicates that he thinks you're an idiot, and (2) that he
| himself participated in the NIST PQC KEM contest _with a
| lattice construction_.
| mswphd wrote:
| there are no meaningful questions. The only way there are
| meaningful questions is if you think global cryptographers +
| governments are part of a cabal to build insecure schemes.
| The new schemes use
|
| 1. cryptography developed across the world, 2. the actual
| schemes were overwhelmingly by European authors 3.
| standardized by the US 4. other countries standardizations
| have been substantially similar (e.g. the ongoing Korean one,
| the German BSI's recommendations. China's CACR [had one with
| substantially similar
| schemes](https://www.sdxcentral.com/analysis/china-russia-to-
| adopt-sl...). Note that this is separate from a
| "standardization", which sounds like it is starting soon).
|
| In particular, given that China + the US ended up with
| (essentially the same) underlying math, you'd have to have a
| _very weird_ hypothetical scenario for the conclusion to not
| be "these seem secure", and instead "there is a global cabal
| pushing insecure schemes".
| PUSH_AX wrote:
| 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 wrote:
| Can a theoretical strong enough quantum computer break PFS?
| wahern wrote:
| 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.
| OkayPhysicist wrote:
| 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 wrote:
| > _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.
| OkayPhysicist wrote:
| It's the same logic as any offensive technology: maybe the
| world would be a better place if we never invented the
| technology, but we can't risk our enemies having it while
| we don't, and even if they never develop it maybe it'll
| help us, and we're the good guys.
|
| Luckily, in this particular arms race, all we the public
| need to do is swap encryption algorithms, and there's no
| risk of ending global civilization if we mess up. So we get
| the best of both worlds: Quantum computing for civilian
| purposes (simulations and whatnot), while none of the
| terrifying surveillance capabilities. We just need to
| update a couple of libraries.
| tptacek wrote:
| 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 wrote:
| > 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 wrote:
| There's a simultaneous push coming from the government to
| support PQC, ASAP, so it's not just researchers pushing
| this.
| evil-olive wrote:
| 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/
| 20k wrote:
| 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
| bwesterb wrote:
| At least it's time bound: hope to have this job done by 2029!
| Hasz wrote:
| 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 wrote:
| 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).
| cetinsert wrote:
| 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 wrote:
| That is a beautiful api.
| hackerman70000 wrote:
| 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 wrote:
| 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.
| rdl wrote:
| 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).
| stingraycharles wrote:
| > 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
| fc417fc802 wrote:
| Does it? That one is different because IPv4 with CGNAT
| largely "just works" except for P2P type stuff. As a result
| there's a strong incentive for anyone who has a working setup
| to just not care.
|
| I can use myself as an example here. IPv6 is supported by all
| my hardware, all the software I use, and my ISP provides it.
| Yet my LAN intentionally remains IPv4 only with NAT. Why?
| Because adding IPv6 to my LAN would require nonzero effort on
| my part and has (at least for now) quite literally zero
| upside for me. If I ever need something it offers I will
| switch to it but that hasn't happened yet.
|
| PQC is entirely different in that the existence of a CRQC
| immediately breaks the security guarantee.
| bwesterb wrote:
| 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
| jeroenhd wrote:
| 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 wrote:
| 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 wrote:
| There is no reason to not support non quantum safe algorithms
| for foreseeable future in the first place
| greesil wrote:
| You did not increase comprehension by not using a single
| negative.
| lexlambda wrote:
| > 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.
| tombert wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| exchange will be strictly slower than an ECC-only key
| exchange.
|
| 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...).
| mswphd wrote:
| they are much more thoroughly vetted than other schemes.
| They're more thoroughly vetted than elliptic curves were before
| we deployed them. Much more vetted than RSA was ever.
|
| Practically though, there are some downsides. Elliptic curves
| tend to have smaller ciphertexts/keys/signatures/so are better
| on bandwidth. If you do everything right with elliptic curves,
| we're also more confident in the hardness of the underlying
| problems (cf "generic group lower bounds", and other extensions
| of this model).
|
| The new algorithms tend to be easier to implement (important,
| as a _big_ source of practical insecurity is implementation
| issues. historically much more than the underlying assumption
| breaking). This isn 't uniformly, e.g. I still think that the
| FN-DSA algorithm will have issues of this type, but ML-DSA and
| ML-KEM are fine. They're also easier to "specify", meaning it
| is much harder to accidentally choose a "weak" instance of them
| (in several senses. the "weak curve" attacks are not really
| possible. there isn't really a way to hide a NOBUS backdoor
| like there was for DUAL_EC_DRBG). They also tend to be faster.
| srdjanr wrote:
| AFAIK, PQ certificates are significantly longer than current
| ones. I don't know exact numbers though.
| MrRadar wrote:
| 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).
| ossianericson wrote:
| 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.
| weightedreply wrote:
| Any information on future CPU's with support for hardware
| accelerated PQC algorithms? Will all my old devices become slow
| when PQC is the norm and encrypted communication is no longer
| hardware accelerated?
| mswphd wrote:
| you don't really need that tbh. you can get pretty good
| speedups using standard (vector) intrinsics. the new algorithms
| are (mostly) modular linear algebra (+ some concept of
| "noise").
| MrRadar wrote:
| Only the asymmetric portion of the cryptography (which is only
| used in the handshake) will need to use PQC algorithms.
| Symmetric crypto algorithms (AES/ChaCha20/SHA-*), which are
| used after the handshake, are not as badly affected by quantum
| computing so they're not being replaced in the immediate term.
| I'm pretty sure that general purpose CPUs do not have hardware
| acceleration for the asymmetric crypto anyways.
| wofo wrote:
| Does this mean we should be migrating our SSH keys to post-
| quantum crypto right now?
| crote wrote:
| OpenSSH has supported post-quantum key agreement since 2022,
| and since 10.1 (October 2025) you'll get a warning if your
| connection isn't using it. It doesn't require rotating your
| keys, just upgrading the software on both sides.
|
| Post-quantum signatures _will_ require rotating your keys, but
| that 's less urgent.
| TacticalCoder wrote:
| Tangential question...
|
| Seen that many are already moving to QC-resistant cryptography
| and that more are shifting by the day... I've got a question:
| what are the implications of quantum computers going to be _if we
| consider that the entirety of cryptography will have moved to
| quantum-resistant cryptography_?
|
| In other words: I only ever read about quantum computing when
| it's to talk about breaking cryptography. But what _if_ all
| cryptography moves to quantum-resistant scheme, all of it... Then
| what are the uses of quantum computing? Protein folding?
| Logistics?
|
| Basically, so far, quantum computing research has the effect of
| many companies and projects adding quantum-resistant
| cryptographic schemes.
|
| If, say, we've got a $10 million quantum computer that can break
| one 256 bit elliptic curve key in an hour... Great, EC is broken.
| But what if browsers, SSH, auth, etc. just about everything moves
| to PQ schemes...
|
| Then what are those quantum computers useful for?
|
| I understand that breaking even a single EC 256 bit key in a few
| hours on a $$$ machine is a very big deal.
|
| But what else are they going to be _useful_ for? For breaking ECC
| doesn 't help humanity. It doesn't bring anything. It only
| destroys.
|
| EDIT: for example I read stuff like: _" Estimates are about three
| years to break a single 256 bit EC key on a 10 000 qbits quantum
| computer"_. What's a 10 000 qbits quantum computer going to be
| used for when everybody shall have moved to quantum-resistant
| algos?
| nalekberov wrote:
| Yet, the same Cloudflare wants to control entire internet traffic
| single-handedly.
|
| Internet was not created for this.
|
| One could argue that "but they are very good at preventing DDoS
| attacks", yes they are, however they always loved control and
| kept their technology proprietary to keep their customers locked
| in their systems, and one day, just single line of code disrupted
| many services on the web.
|
| Centralization and monopolies are much bigger threats for the
| future of the internet IMHO. (Which always follows the same
| pattern, give your customer free or unbelievably cheaper
| services, be it a lost lead, lock them in, jack up the price)
___________________________________________________________________
(page generated 2026-04-07 23:00 UTC)