[HN Gopher] A cryptography engineer's perspective on quantum com...
___________________________________________________________________
A cryptography engineer's perspective on quantum computing
timelines
Author : thadt
Score : 266 points
Date : 2026-04-06 15:31 UTC (7 hours ago)
(HTM) web link (words.filippo.io)
(TXT) w3m dump (words.filippo.io)
| pdhborges wrote:
| What do you recomend as reading material for someone that was in
| college a while ago (before AE modes got popular) to get up to
| speed with the new PQ developments?
| FiloSottile wrote:
| If you want something book-shaped, the 2nd edition of Serious
| Cryptography is updated to when the NIST standards were near-
| final drafts, and has a nice chapter on post-quantum
| cryptography.
|
| If you want something that includes details on how they were
| deployed, I'm afraid that's all very recent and I don't have
| good references.
| vonneumannstan wrote:
| This seems like something uniquely suited to the startup
| ecosystem. I.e. offering PQ Encryption Migration as a Service. PQ
| algorithms exist and now theres a large lift required to get them
| into the tech with substantial possible value.
| hlieberman wrote:
| ... really? This is simultaneously so far down in the plumbing
| and extremely resistant to measuring the impact of, I can't
| imagine anyone building a company off of this that's not
| already deep in the weeds (lookin' at you, WolfSSL).
|
| The idea that a startup would be competitive in the VC "the
| only thing that matters are the feels" environment seems crazy
| to me.
| OhMeadhbh wrote:
| Yeah... I spent the 90s working for RSADSI and Certicom
| implementing algorithms. Crypto is a vitamin, not an aspirin.
| Hardly anyone is capable of properly assessing risk in
| general, much less the technical world of information risk
| management. Telling someone they should pay you money to
| reduce the impact of something that may or may not happen in
| the future is not a sales win.
| tux3 wrote:
| This is a good take, there's really not much to argue about.
|
| >[...] the availability of HPKE hybrid recipients, which blocked
| on the CFRG, which took almost two years to select a stable label
| string for X-Wing (January 2024) with ML-KEM (August 2024),
| despite making precisely no changes to the designs. The IETF
| should have an internal post-mortem on this, but I doubt we'll
| see one
|
| My kingdom for a standards body that discusses and resolves
| process issues.
| OhMeadhbh wrote:
| I missed you at the most recent CRFG meeting.
| adgjlsfhk1 wrote:
| I think the anti-hybrid argument the article makes is clearly
| wrong. Even if CRQCs existed today, we still should be using
| hybrid algorithms because even once CRQCs exist, they will be
| slow, expensive, and power hungry for at least a decade. The
| hybrid algorithms at a minimum make the cost of any attack
| ~$1M, which is way better than half of the PQC algorithms that
| made it to the 3rd stage of the PQC competition (2 of them can
| be broken on a laptop)
| scythmic_waves wrote:
| Is it?
|
| Your reasoning relies on this being true:
|
| > [CRQCs] will be slow, expensive, and power hungry for at
| least a decade
|
| How could you know that? What if it was 5 years? 1 year? 6
| months?
|
| I predict there will be an _insane_ global pivot once Q-day
| arrives. No nation wants to invest billions in science
| fiction. Every nation wants to invest billions in a practical
| reality of being able to read everyone 's secrets.
| adgjlsfhk1 wrote:
| The absolute low end of cost of a QC is the cost of an MRI
| machine ~100k-400k (cost of cooling the computer to super
| low temps). Sure we expect QCs to get faster and cheaper
| over time, but putting 100% faith in the security of the
| PQC algorithms seems like a bad idea with no upside.
| FiloSottile wrote:
| We can disagree on the tradeoff, but if you see no
| upside, you are missing the velocity cost of the
| specification work, the API design, and the
| implementation complexity. Plus the annoying but real
| social cost of all the bikeshedding and bickering.
| phicoh wrote:
| It is the paradox of PQC: from a classical security point
| of view PQC cannot be trusted (except for hash-based
| algorithms which are not very practical). So to get
| something we can trust we need hybrid. However, the
| premise for introducing PQC in the first place is that
| quantum computers can break classical public key crypto,
| so hybrid doesn't provide any benefit over pure PQC.
|
| Yes, the sensible thing to do is hybrid. But that does
| assume that either PQC cannot be broken by classical
| computers or that quantum computers will be rare or
| expensive enough that they don't break your classical
| public key crypto.
| FiloSottile wrote:
| > from a classical security point of view PQC cannot be
| trusted
|
| [citation needed]
|
| https://words.filippo.io/crqc-timeline/#fn:lattices
| OhMeadhbh wrote:
| In rebuttal, Peter Gutmann seems to think the progress towards
| quantum computing devices which can break commonly used public
| key crypto systems is not moving especially quickly:
| https://eprint.iacr.org/2025/1237
| schmichael wrote:
| That's not a rebuttal. The post references the paper and a
| rebuttal to it from an expert in the field.
| OhMeadhbh wrote:
| Damn. It's like I insulted Vault.
|
| Also, I went over Filippo's post again and still can't see
| where it references the Gutmann / Neuhaus paper. Are we
| talking about the same post?
| tkhattra wrote:
| From Filippo's post: "Sure, papers about an abacus and a
| dog are funny and can make you look smart and contrarian on
| forums."
| commandersaki wrote:
| Is that even a rebuttal? Seems like just a dismissal
| without any substance. I expect in 10 years the
| predictions will be wrong, kind of like Y2K all over
| again.
| OhMeadhbh wrote:
| If only we had a technology where an author could specify
| a unique identifier and name of another author's paper.
| Something that could cite a different paper and link to
| it.
| xvector wrote:
| From the abstract:
|
| > This paper presents implementations that match and, where
| possible, exceed current quantum factorisation records
| using a VIC-20 8-bit home computer from 1981, an abacus,
| and a dog.
|
| From the link:
|
| > Sure, papers about an abacus and a dog are funny and can
| make you look smart and contrarian on forums. But that's
| not the job, and those arguments betray a lack of
| expertise[1]. As Scott Aaronson said[2]:
|
| > > Once you understand quantum fault-tolerance, asking "so
| when are you going to factor 35 with Shor's algorithm?"
| becomes sort of like asking the Manhattan Project
| physicists in 1943, "so when are you going to produce at
| least a small nuclear explosion?"
|
| [1]:
| https://bas.westerbaan.name/notes/2026/04/02/factoring.html
|
| [2]: https://scottaaronson.blog/?p=9665#comment-2029013
| john_strinlai wrote:
| > _and a rebuttal to it from an expert in the field._
|
| while i agree with filippo, the way you worded this makes me
| think that you may not be aware that gutmann is also an
| expert in the field. so, if you are giving filippo weight
| because he is an expert, it is worth giving some amount to
| gutmann as well.
| schmichael wrote:
| I apologize if I flippantly dismissed the fact that experts
| disagree. That was not my intention. I was trying to point
| out that OP does address the referenced counter-point post
| specifically.
| john_strinlai wrote:
| > _Sorry if I flippantly dismissed the fact that experts
| disagree!_
|
| i dont really get your reply/insincere apology.
|
| if you are going to bother mentioning filippo's expertise
| in the first place, its just weird to frame it the way
| you did. that is how someone would typically dismiss some
| random blogger with an appeal to authority. but if both
| people are authorities, it doesnt make sense.
|
| if you already knew, than my comment can be context for
| future readers that dont and might just dismiss gutmann
| as a non-expert getting rebutted by an expert.
| OsrsNeedsf2P wrote:
| Why do we "need to ship"? 1,000 qubit quantum computers are still
| decades away at this point
| OhMeadhbh wrote:
| So... In 2013 I was working for Mozilla adding TLS 1.1 and 1.2
| support into Firefox. It turns out that some of the extensions
| common in 1.1, in some instances caused PDUs to grow beyond 16k
| (or maybe it was 32k, can't remember.). This caused middle
| boxes to barf. Sure, they shouldn't barf, but they did. We
| discovered the problem (or rather one of our users discovered
| the problem) by increasing the key size on server and client
| certs to push PDU sizes over the limit.
|
| At the very least, you want to start using hybrid legacy / pqc
| algorithms so engineers at Cisco will know not to limit key
| sizes in PDUs to 128 bytes.
| ekr____ wrote:
| A few points here: There is already very wide use of PQ
| algorithms in the Web context [0], which is the most
| problematic one because clients need to be able to connect to
| any site and there's no real coordination between sites and
| clients. So we're exercising the middleboxes already.
|
| The incident you're thinking of doesn't sound familiar. None
| of the extensions in 1.1 really were that big, though of
| course certs can get that big if you work hard enough. Are
| you perhaps thinking instead of the 256-511 byte ClientHello
| issue addressed ion [1]
|
| [0] https://blog.cloudflare.com/pq-2025/ [1]
| https://datatracker.ietf.org/doc/html/rfc7685
| OhMeadhbh wrote:
| Oh hey Eric. I think I was wrong saying it was 1.1. It was
| a middlebox that ignored max fragment negotiation, which I
| think was introduced in 1.2. IIRC, the middlebox claimed to
| support it for 1.2 connections, but silently failed by
| blackholing the connection. They eventually crafted a fix,
| but it was an annoying year waiting for network operators
| to upgrade the firmware on their routers.
| Sparkyte wrote:
| There is always a price to encryption. The cost goes up the more
| you have to cater to different and older encryptions while
| supporting the latest.
| munrocket wrote:
| Yes, this is why I invested in QRL crypto. With lates updates and
| no T1 exchange it looks like a good opportunity to grow.
| adrian_b wrote:
| It should be noted that if indeed there has not remained much
| time until a usable quantum computer will become available, the
| priority is the deployment of FIPS 203 (ML-KEM) for the
| establishment of the secret session keys that are used in
| protocols like TLS or SSH.
|
| ML-KEM is intended to replace the traditional and the elliptic-
| curve variant of the Diffie-Hellman algorithm for creating a
| shared secret value.
|
| When FIPS 203, i.e. ML-KEM is not used, adversaries may record
| data transferred over the Internet and they might become able to
| decrypt the data after some years.
|
| On the other hand, there is much less urgency to replace the
| certificates and the digital signature methods that are used
| today, because in most cases it would not matter if someone would
| become able to forge them in the future, because they cannot go
| in the past to use that for authentication.
|
| The only exception is when there would exist some digital
| documents that would completely replace some traditional paper
| documents that have legal significance, like some documents
| proving ownership of something, which would be digitally signed,
| so forging them in the future could be useful for somebody, in
| which case a future-proof signing method would make sense for
| them.
|
| OpenSSH, OpenSSL and many other cryptographic libraries and
| applications already support FIPS 203 (ML-KEM), so it could be
| easily deployed, at least for private servers and clients,
| without also replacing the existing methods used for
| authentication, e.g. certificates, where using post-quantum
| signing methods would add a lot of overhead, due to much bigger
| certificates.
| FiloSottile wrote:
| That was my position until last year, and pretty much a
| consensus in the industry.
|
| What changed is that the new timeline might be so tight that
| (accounting for specification, rollout, and rotation time) the
| time to switch authentication has _also_ come.
|
| ML-KEM deployment is tangentially touched on in the article
| because it's both uncontroversial and underway, but:
|
| > This is not the article I wanted to write. I've had a pending
| draft for months now explaining we should ship PQ key exchange
| now, but take the time we still have to adapt protocols to
| larger signatures, because they were all designed with the
| assumption that signatures are cheap. That other article is now
| wrong, alas: we don't have the time if we need to be finished
| by 2029 instead of 2035.
|
| > For key exchange, the migration to ML-KEM is going well
| enough but: 1. Any non-PQ key exchange should now be considered
| a potential active compromise, worthy of warning the user like
| OpenSSH does, because it's very hard to make sure all secrets
| transmitted over the connection or encrypted in the file have a
| shorter shelf life than three years. [...]
|
| You comment is essentially the premise of the other article.
| adrian_b wrote:
| I agree with you that one must prepare for the transition to
| post-quantum signatures, so that when it becomes necessary
| the transition can be done immediately.
|
| However that does not mean that the switch should really be
| done as soon as it is possible, because it would add
| unnecessary overhead.
|
| This could be done by distributing a set of post-quantum
| certificates, while continuing to allow the use of the
| existing certificates. When necessary, the classic
| certificates could be revoked immediately.
| FiloSottile wrote:
| How do you do revocation or software updates securely if
| your current signature algorithm is compromised?
| ekr____ wrote:
| As a practical matter, revocation on the Web is handled
| mostly by centrally distributed revocation lists
| (CRLsets, CRLite, etc. [0]), so all you really need is:
|
| (1) A PQ-secure way of getting the CRLs to the browser
| vendors. (2) a PQ-secure update channel.
|
| Neither of these require broad scale deployment.
|
| However, the more serious problem is that if you have a
| setting where most servers do not have PQ certificates,
| then disabling the non-PQ certificates means that lots of
| servers can't do secure connections at all. This
| obviously causes a lot of breakage and, depending on the
| actual vulnerability of the non-PQ algorithms, might not
| be good for security either, especially if people fall
| back to insecure HTTP.
|
| See: https://educatedguesswork.org/posts/pq-emergency/
| and https://www.chromium.org/Home/chromium-security/post-
| quantum...
|
| [0] The situation is worse for Apple.
| FiloSottile wrote:
| Indeed, in an open system like the WebPKI it's fine in
| theory to only make the central authority PQ, but then
| you have the ecosystem adoption issue. In a closed
| system, you don't have the adoption issue, but the
| benefit to making only the central authority PQ is likely
| to be a lot smaller, because it might actually be the
| only authority. In both cases, you need to start moving
| now and gain little from trying to time the switchover.
| ekr____ wrote:
| > In both cases, you need to start moving now and gain
| little from trying to time the switchover.
|
| There are a number of "you"s here, including:
|
| - The SDOs specifying the algorithms (IETF mostly)
|
| - CABF adding the algorithms to the Baseline Requirements
| so they can be used in the WebPKI
|
| - The HSM vendors adding support for the algorithms
|
| - CAs adding PQ roots
|
| - Browsers accepting them
|
| - Sites deploying them
|
| This is a very long supply line and the earlier players
| do indeed need to make progress. I'm less sure how
| helpful it is for individual sites to add PQ certificates
| right now. As long as clients will still accept non-PQ
| algorithms for those sites, there isn't much security
| benefit so most of what you are doing is getting some
| experience for when you really need it. There are obvious
| performance reasons not to actually have most of your
| handshakes use PQ certificates until you really have to.
| FiloSottile wrote:
| Yeah, that's an audience mismatch, this article is for
| "us." End users of cryptography, including website
| operators and passkey users
| (https://news.ycombinator.com/item?id=47664744) can't do
| much right now, because "we" still need to finish our
| side.
| fireflash38 wrote:
| If your HSM vendor isn't actively working on/have a
| release date for GA PQ, you should probably get a new
| vendor.
| btilly wrote:
| Planning now on a fast upgrade later, is planning on
| discovering all of the critical bugs after it is too late
| to do much about them.
|
| Things need to be rolled out in advance of need, so that
| you can get a do-again in case there proves to be a need.
| snowwrestler wrote:
| > I agree with you that one must prepare for the transition
| to post-quantum signatures, so that when it becomes
| necessary the transition can be done immediately.
|
| Personally, my reading between the lines on this subject as
| a non-expert is that we in the public might not know when
| post-quantum cryptography is necessary until quite a while
| after it is necessary.
|
| Prior to the public-key cryptography revolution, the state
| of the art in cryptography was locked inside state
| agencies. Since then, public cryptographic research has
| been ahead or even with state work. One obvious tell was
| all the attempts to force privately-operated cryptographic
| schemes to open doors to the government via e.g. the
| Clipper chip and other appeals to magical key escrow.
|
| A whole generation of cryptographers grew up in this world.
| Quantum cryptography might change things back. We know what
| papers say from Google and other companies. Who knows what
| is happening inside the NSA or military facilities?
|
| It seems that with quantum cryptography we are back to
| physics, and the government does secret physics projects
| really well. This paragraph really stood out to me:
|
| > Scott Aaronson tells us that the "clearest warning that
| [he] can offer in public right now about the urgency of
| migrating to post-quantum cryptosystems" is a vague
| parallel with how nuclear fission research stopped
| happening in public between 1939 and 1940.
| raron wrote:
| > Since then, public cryptographic research has been
| ahead or even with state work.
|
| How can we know that?
|
| > Who knows what is happening inside the NSA or military
| facilities?
|
| Couldn't have NSA found an issue with ML-KEM and try to
| convince people to use it exclusively (not in hybrid
| scheme with ECC)?
| goalieca wrote:
| Follow nsa suite-b and what the USA forces on different
| levels of classification.
| layer8 wrote:
| > The only exception is when there would exist some digital
| documents that would completely replace some traditional paper
| documents that have legal significance, like some documents
| proving ownership of something, which would be digitally
| signed, so forging them in the future could be useful for
| somebody, in which case a future-proof signing method would
| make sense for them.
|
| This very much exists. In particular, the cryptographic
| timestamps that are supposed to protect against future
| tampering are themselves currently using RSA or EC.
| ekr____ wrote:
| Yes, though we do know how to solve this problem by using
| hash-based timestamping systems. See:
| https://link.springer.com/article/10.1007/BF00196791
|
| Of course, the modern version of this is putting the
| timestamp and a hash of the signature on the blockchain.
| janalsncm wrote:
| Building out a supercomputer capable of breaking cryptography is
| exactly the kind of thing I expect governments to be working on
| now. It is referenced in the article, but the analogy to the
| Manhattan Project is clear.
|
| Prior to 1940 it was known that clumping enough fissile material
| together could produce an explosion. There were engineering
| questions around how to purify uranium and how to actually
| construct the weapon etc. But the phenomenon was known.
|
| I say this because there's a meme that governments are cooking up
| exotic technologies behind closed doors which I personally tend
| to doubt.
|
| This is almost perfect analogy to the MP though. We know exactly
| what could happen if we clumped enough qubits together. There are
| hard engineering challenges of actually doing so, and governments
| are pretty good at clumping dollars together when they want to.
| bitexploder wrote:
| The Manhattan project employed some significant % of all of
| America. A project of that scale will likely never happen
| again.
|
| It was also about far more than the science. It was about
| industrializing the entire production process and creating
| industrial capability that simply did not exist before.
| janalsncm wrote:
| My comment was not limited to the U.S. government.
|
| And the Manhattan Project cost $30B in today's money.
| Compared with some of the numbers Congress has allocated
| recently, I'd call that a bargain.
| bastawhiz wrote:
| Does quantum computing need that though? We don't suddenly
| need a large, unique supply chain for these computers. We
| don't need to dig up the qubits and refine them. Testing
| doesn't blow up the computer.
| O3marchnative wrote:
| > There were engineering questions around how to purify uranium
| and how to actually construct the weapon etc. But the
| phenomenon was known.
|
| FWIW, constructing a weapon with highly enriched uranium is,
| relatively, simple. At the time, the choice was made to use a
| gun-type weapon that shot a projectile of highly enriched
| uranium into a a "target" of highly enriched uranium. The
| scientists were so sure it would work that the design didn't
| necessitate a live test. This was "little boy", which was
| eventually dropped on Hiroshima.
|
| Fat Man utilized plutonium which required an implosion to
| compress the fissile material that would set off the chain
| reaction. This is a much more complex undertaking, but it's
| much more efficient. Namely, you need much less fissile
| material, and more of that fissile material is able to
| participate in the chain reaction. This design is what allows
| for nuclear tipped missiles. The same principles can be applied
| to a U-235 based weapon as well.
|
| The implosion based design is super interesting to read about.
| One memorable aspect is that the designers realized that
| applying a tamper of uranium (U-238) around the fissile
| material allows for significant improvement in yield. The chain
| reaction is exponential, so the few extra nanoseconds that the
| uranium keeps the fissile material together leads to
| significant increase in yield.
|
| https://en.wikipedia.org/wiki/Little_Boy
|
| https://en.wikipedia.org/wiki/Fat_Man
| amluto wrote:
| I was in this field a while back, and I always found it baffling
| that anyone ever believed in the earlier large estimates for the
| size of a quantum computer needed to run Shor's algorithm. For a
| working quantum computer, Shor's algorithm is about as difficult
| as modular exponentiation or elliptic curve scalar
| multiplication: if it can compute or verify signatures or encrypt
| or decrypt, then it can compute discrete logs. To break keys of a
| few hundred bits, you need a few hundred qubits plus not all that
| much overhead. And the error correction keeps improving all the
| time.
|
| Also...
|
| > Trusted Execution Environments (TEEs) like Intel SGX and AMD
| SEV-SNP and in general hardware attestation are just f**d. All
| their keys and roots are not PQ and I heard of no progress in
| rolling out PQ ones, which at hardware speeds means we are forced
| to accept they might not make it, and can't be relied upon.
|
| This part is embarrassing. We've had hash-based signatures that
| are plenty good for this for years and inspire more confidence
| for long-term security than the lattice schemes. Sure, the
| private keys are bigger. So what?
|
| We will also need some clean way to upgrade WebAuthn keys, and
| WebAuthn key management currently massively sucks.
| hujun wrote:
| > Trusted Execution Environments (TEEs) like Intel SGX and AMD
| SEV-SNP and in general hardware attestation are just f*d. All
| their keys and roots are not PQ and I heard of no progress in
| rolling out PQ ones, which at hardware speeds means we are
| forced to accept they might not make it, and can't be relied
| upon.
|
| compare to SGX, a more critical impacted component is TPM chip,
| secured/measured boot depends on TPM, and cost of replacing all
| servers and OS ...
| amluto wrote:
| A lot of TPMs are "fTPM"s, which are implemented in something
| resembling software. It's an open question whether the
| hardware in question has usable roots of trust, but a lot of
| TPM applications don't actually require endorsement. And some
| servers have plug-in TPMs.
|
| Of course, many critical components on a motherboard and CPU
| verify their firmware using non-post-quantum keys, which is
| another issue.
| palata wrote:
| What is the consequence on e.g. Yubikeys (or say the Android
| Keystore)? Do I understand correctly that those count as
| "signature algorithms" and are a little less at risk than "full
| TEEs" because there is no "store now, decrypt later" for
| authentication?
|
| E.g. can I use my Yubikey with FIDO2 for SSH together with a PQ
| encryption, such that I am safe from "store now, decrypt later",
| but can still use my Yubikey (or Android Keystore, for that
| matter)?
| amluto wrote:
| Your Yubikey itself is doomed.
|
| If you are doing a post-quantum key exchange and only
| authenticating with the Yubikey, then you are safe from after-
| the-fact attacks. Well, as long as the PQ key exchange holds
| up, and I am personally not as optimistic about that as I'd
| like to be.
| elevation wrote:
| Looking forward to a PQ yubikey rev. I would buy a box of
| them today so I could start experimenting!
|
| Another challenge of the transition is how much silicon we
| have yet to even implement. Smart cards? Mobile
| acceleration/offloading? We're at the mercy of vendors.
| ls612 wrote:
| Is this also true for other TPM/snitching/DRM chips out
| there? IE will every existing device eventually become
| jailbreakable in the future or will we unfortunately not even
| get that benefit from all this?
| ameliaquining wrote:
| The timeline here is for when _major governments_ have
| access to CRQCs. It will be much longer than that (barring
| an AI singularity or something) before _you_ have access to
| one.
| palata wrote:
| > If you are doing a post-quantum key exchange and only
| authenticating with the Yubikey, then you are safe from
| after-the-fact attacks.
|
| Let me rephrase it to see if I understand correctly: so it is
| fine to keep using my security keys today _for
| authentication_ (e.g. FIDO2?), but everything else should use
| PQ algorithm because the actual data transfers can be stored
| now and decrypted later.
|
| Meaning that _today_ (and for a few years), my Yubikey still
| protects me from my key being stolen when my OS is
| compromised.
|
| Correct?
| FiloSottile wrote:
| This article is more aimed at those specifying and implementing
| WebAuthN and SSH, than at those using them.
|
| They/we need to migrate those protocols to PQ now, so that you
| all can start migrating to PQ keys in time, including the long
| tail of users that will not rotate their keys and hardware the
| moment the new algorithms are supported.
|
| For example, it _might_ be too late to get anything into Debian
| for it to be in oldstable when the CRQCs come!
| palata wrote:
| > This article is more aimed at those specifying and
| implementing WebAuthN and SSH, than at those using them.
|
| Sure, I'm just trying to understand the consequences of that.
| Felt great to finally have secure elements on smartphones and
| laptops (or Yubikeys), protecting against the OS being
| compromised (i.e. "you access my OS, but at least you can't
| steal my keys").
|
| I was wondering if PQ meant that when it becomes reality, we
| just get back to a world where if our OS is compromised, then
| our keys get compromised, too. Or if there is a middle ground
| in the threat model, e.g. "it's okay to keep using your
| Yubikey, because an attacker would need to have physical
| access to your key, specialised hardware AND access to a
| quantum computer in order to break it". Versus "you can stop
| bothering about security keys because with "store now,
| decrypt later", everything you do today with your security
| keys will anyway get broken with quantum computers
| eventually".
| FiloSottile wrote:
| If you are doing _authentication_ with those hardware keys,
| you will probably be fine, if we do our job fast enough.
| Apple 's Secure Enclave already supports some PQ signatures
| (although annoyingly not ML-DSA-44 apparently?) and I trust
| Yubico is working on it.
|
| If you are doing encryption, then you do have reason to
| worry, and there aren't great options right now. For
| example if you are using age you should switch to hybrid
| software ML-KEM-768 + hardware P-256 keys as soon as they
| are available (https://github.com/str4d/age-plugin-
| yubikey/pull/215). This might be a scenario in which
| hybrids provide some protection, so that an attacker will
| need to compromise both your OS _and_ have a CRQC. In the
| meantime, depending on your threat model and the longevity
| of your secrets (and how easily they can rotated in 1-2
| years), it might make sense to switch to software PQ keys.
| palata wrote:
| Thanks a lot, that helps!
|
| > This might be a scenario in which hybrids provide some
| protection, so that an attacker will need to compromise
| both your OS and have a CRQC.
|
| Did you mean "your OS _and_ have a CRQC " here, or "your
| Yubikey _and_ have a CRQC "?
| FiloSottile wrote:
| I mean "your OS and have a CRQC" because they will need
| to compromise the software PQ key by compromising the OS,
| and derive the hardware YubiKey private key using the
| CRQC.
| palata wrote:
| Oh right, I got it now!
| bjourne wrote:
| > Traveling back from an excellent AtmosphereConf 2026, I saw my
| first aurora, from the north-facing window of a Boeing 747.
|
| Given the author's "safety first" stance on pqc, it seems a bit
| incongruent to continue to fly to conferences...
| krunck wrote:
| This would also be a good time for certain governments to
| knowingly push broken PQ KE standards while there is a panicked
| rush to get PQ tech in place.
| some_furry wrote:
| Which governments are you thinking of?
| FiloSottile wrote:
| Remember that the entities most likely to heed those
| governments recommendations are those providing services to
| said government and its military.
|
| I feel like the NSA pushing a (definitely misguided and
| obviously later exploited by adversaries) NOBUS backdoor has
| poorly percolated into the collective consciousness, missing
| the NOBUS part entirely.
|
| See https://keymaterial.net/2025/11/27/ml-kem-mythbusting/ for
| whether the current standards can hide NOBUS backdoors. It
| talks about ML-KEM, but all recent standards I read look like
| this.
| adgjlsfhk1 wrote:
| IMO the idea that NSA only uses NOBUS backdoors is obviously
| false (see for example DES's 56 bit key size). The NSA is
| perfectly capable of publicly calling for an insecure
| algorithm and then having secret documentation to not use it
| for anything important.
| bawolff wrote:
| > see for example DES's 56 bit key size
|
| In fairness, that was from 1975. I don't particularly trust
| the NSA, but i dont think things they did half a century
| ago is a great way to extrapolate their current interests.
| FiloSottile wrote:
| DES is the algorithms that was secretly modified by the NSA
| to _protect it_ against differential cryptanalysis. Capping
| a key size is hardly a "backdoor."
|
| Also, that was the time of export ciphers and Suite A vs
| Suite B, which were very explicit about there being
| different algorithms for US NatSec vs. everything else.
| This time there's only CNSA 2.0, which is pure ML-KEM and
| ML-DSA.
|
| So no, there is no history of the NSA pushing non-NOBUS
| backdoors into NatSec algorithms.
| Animats wrote:
| We'll know it's been cracked when all the lost Bitcoins start to
| move.
| sunshine-o wrote:
| Yep, I was looking into it and from what I understand:
|
| - There is a dark outlook on Bitcoin as the community and devs
| can't seem to coordinate. Especially on what to do with the
| "Satoshi coins"
|
| - Ethereum has a hard but clear path (pretty much full rewrite)
| with a roadmap [0]
|
| - The highly optimized "fast chains" (Solana & co) are in a lot
| of trouble too.
|
| It would be funny if Bitcoin the asset end up migrating to
| Ethereum as another erc20 token
|
| - [0] https://pq.ethereum.org/
| PretzelPirate wrote:
| > pretty much full rewrite
|
| This is far from my understanding. Changing out this
| signature scheme is hard work, but doesn't require a rewrite
| of the VM.
| sunshine-o wrote:
| Ethereum is way more complex than let's say Bitcoin and all
| parts are affected. This is not just the "signature
| scheme".
|
| The fact that the signature size is multiplied by ~10 will
| greatly affect things like blockspace (what I guess is even
| more a problem with Bitcoin !)
|
| Also they are the only blockchain I believe that put an
| emphasis on allowing large number of validators to run on
| very modest hardware (in the ballpark of a RPI, N100 or
| phone).
|
| My understanding is they will need to pack it with a larger
| upgrade to solve all those problems, the so called
| zkVM/leanVM roadmap.
|
| And then there are the L2 that are an integral part of the
| ecosystem.
|
| So this is the greatest upgrade ever made on Ethereum,
| pretty much full rewrite, larger than the transition to
| proof of stake. I remember before the Proof of Stake
| migration they were planning to redo the EVM too (with
| something WASM based at the time) but they had to abandon
| their plan. Now it seems there is no choice but to do it.
| nullc wrote:
| Adding new signature schemes to bitcoin is relatively trivial
| and has been done previously (today Bitcoin supports both
| schnorr and ecdsa signatures).
|
| Existing PQ standards have signatures with the wrong
| efficiency tradeoffs for usage in Bitcoin-- large signatures
| that are durable against a lot of use and supports fast
| signing, while for Bitcoin signature+key size is critical,
| keys should be close to single use, and signing time is
| irrelevant.
|
| To the extent that I've seen any opposition related to this
| isn't only been in related to schemes that were to
| inefficient or related to proposals to confiscate the assets
| of people not adopting the proponent's scheme (which
| immediately raises concerns about backdoors and consent).
|
| There is active development for PQ signature standards
| tailored to Bitcoin's needs, e.g.
| https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-
| sig... and I think progress looks pretty reasonable.
|
| Claims that there is no development are as far as I can tell
| are just backscatter from a massive fraud scheme that is
| ongoing (actually, at least two distinct cons with an almost
| identical script). There are criminal fraudsters out seeking
| investments in a scheme to raise money to build a quantum
| computer and steal Bitcoins. One of them reportedly has
| raised funds approaching a substantial fraction of a billion
| dollars from victims. For every one sucker they convince to
| give them money, they probably create 99 others people
| panicked about it (since believing it'll work is a pre-req to
| handing over your money).
| xvector wrote:
| The bitcoins won't move until the technology is commoditized
| (ie well past mainstream usage by the government.)
|
| Having PQ and your adversaries not knowing is far more valuable
| than the few hundred billion you could get from cracking (and
| tanking) BTC.
| oncallthrow wrote:
| No, it will likely be a state actor who reaches it first, who
| will never give away such a capability so easily
| phicoh wrote:
| What surprises me is how non-linear this argument is. For a
| classical attack on, for example RSA, it is very easy to a factor
| an 8-bit composite. It is a bit harder to factor a 64-bit
| composite. For a 256-bit composite you need some tricky math,
| etc. And people did all of that. People didn't start out
| speculating that you can factor a 1024-bit composite and then one
| day out of the blue somebody did it.
|
| The weird thing we have right now is that quantum computers are
| absolutely hopeless doing anything with RSA and as far as I know,
| nobody even tried EC. And that state of the art has not moved
| much in the last decade.
|
| And then suddenly, in a few years there will be a quantum
| computer that can break all of the classical public key crypto
| that we have.
|
| This kind of stuff might happen in a completely new field. But
| people have been working on quantum computers for quite a while
| now.
|
| If this is easy enough that in a few years you can have a quantum
| computer that can break everything then people should be able to
| build something in a lab that breaks RSA 256. I'd like to see
| that before jumping to conclusions on how well this works.
| FiloSottile wrote:
| See https://bas.westerbaan.name/notes/2026/04/02/factoring.html
| and https://scottaaronson.blog/?p=9665#comment-2029013 which
| are linked to in the first section of the article.
|
| > Sure, papers about an abacus and a dog are funny and can make
| you look smart and contrarian on forums. But that's not the
| job, and those arguments betray a lack of expertise. As Scott
| Aaronson said:
|
| > Once you understand quantum fault-tolerance, asking "so when
| are you going to factor 35 with Shor's algorithm?" becomes sort
| of like asking the Manhattan Project physicists in 1943, "so
| when are you going to produce at least a small nuclear
| explosion?"
|
| To summarize, the hard part of scalable quantum computation is
| error correction. Without it, you can't factorize essentially
| anything. Once you get _any_ practical error correction, the
| distance between 32-bit RSA and 2048-bit RSA is small.
| Similarly to how the hard part is to cause a self-sustaining
| fissile chain reaction, and once you do making the bomb bigger
| is not the hard part.
|
| This is what the experts know, and why they tell us of the
| timelines they do. We'd do better not to dismiss them by being
| smug about our layperson's understanding of their progress
| curve.
| phicoh wrote:
| The thing is, producing the right isotopes of uranium is
| mostly a linear process. It goes faster as you scale up of
| course, but each day a reactor produces a given amount. If
| you double the number of reactors you produce twice as much,
| etc.
|
| There is no such equivalent for qubits or error correction.
| You can't say, we produce this much extra error correction
| per day so we will hit the target then and then.
|
| There is also something weird in the graph in
| https://bas.westerbaan.name/notes/2026/04/02/factoring.html.
| That graph suggests that even with the best error correction
| in the graph, it is impossible to factor RSA-4 with less then
| 10^4 qubits. Which seems very odd. At the same time, Scott
| Aaronson wrote: "you actually can now factor 6- or 7-digit
| numbers with a QC". Which in the graph suggests that error
| rate must be very low already or quantum computers with an
| insane number of qubits exist.
|
| Something doesn't add up here.
| adgjlsfhk1 wrote:
| You can already factor a 6 digit number with a QC, but not
| with an algorithm that scales polynomially. The graph
| linked is for optimized variants of Shor's algorithm.
| FiloSottile wrote:
| We are stretching the metaphor thin, but surely the
| progress towards an atomic bomb was not measured only in
| uranium production, in the same way that the progress
| towards a QC is not measured only in construction time of
| the machine.
|
| At the theory level, there were only theories, then a few
| breakthroughs, then some linear production time, then a big
| boom.
|
| > Something doesn't add up here.
|
| Please consider it might be your (and my) lack of expertise
| in the specific sub-field. (I do realize I am saying this
| on Hacker News.)
| octoberfranklin wrote:
| > produce at least a small nuclear explosion
|
| The Manhattan Project scientists _actually did this_ before
| anybody broke ground at Los Alamos. It was called the Chicago
| Pile. And if the control rods were removed and the SCRAM
| disabled, it absolutely would have created a "small nuclear
| explosion" in the middle of a major university campus.
|
| Given the level of hype and how long it's been going on, I
| think it's totally reasonable for the wider world to ask the
| quantum crypto-breaking people to build a Chicago Pile first.
|
| https://en.wikipedia.org/wiki/Chicago_Pile-1
| FiloSottile wrote:
| TIL about the Chicago Pile! (I don't know enough about the
| physics to tell if it could have indeed exploded.)
|
| > On 2 December 1942
|
| https://en.wikipedia.org/wiki/Chicago_Pile-1
|
| > on July 16, 1945
|
| https://en.wikipedia.org/wiki/Trinity_(nuclear_test)
|
| Two years and a half. This is still a good metaphor for
| "once you can make a small one, the large one is not far at
| all."
| tptacek wrote:
| What? No. No matter what anybody did with the Chicago Pile,
| it would never have produced a small version of a nuclear
| detonation.
| thhoo5886gjggy wrote:
| IIRC the largest number factored still remains 21
| venusenvy47 wrote:
| His article specifically mentions that the threat is with the
| public key exchange, not the encryption that happens after the
| key exchange.
| xoa wrote:
| Yeah, sounds like it's time to take this very seriously. Sobering
| article to read, practical and to the point on risk posture. One
| brief paragraph though that I think deserves extra emphasis and I
| don't see in the comments here yet:
|
| > _In symmetric encryption, we don't need to do anything,
| thankfully_
|
| This is valuable because it does offer a non-scalable but very
| important extra layer that a lot of us will be able to implement
| in a few important places today, or could have for awhile even. A
| lot of people and organizations here may have some critical
| systems where they can make a meat-space-man-power vs security
| trade by virtue of pre-shared keys and symmetric encryption
| instead of the more convenient and scalable normal pki. For me
| personally the big one is WireGuard, where as of a few years ago
| I've been able to switch the vast majority of key site-to-site
| VPNs to using PSKs. This of course requires out of band, ie,
| huffing it on over to every single site, and manually sharing
| every single profile via direct link in person vs conveniently
| deployable profiles. But for certain administrative capability
| where the magic circle in our case isn't very large this has been
| doable, and it gives some leeway there as any traffic being
| collected now or in the future will be worthless without actual
| direct hardware compromise.
|
| That doesn't diminish the importance of PQE and industry action
| in the slightest and it can't scale to everything, but you may
| have software you're using capable of adding a symmetric layer
| today without any other updates. Might be worth considering as
| part of low hanging immediate fruit for critical stuff. And maybe
| in general depending on organization and threat posture might be
| worth imagining a worst-case scenario world where symmetric and
| OTP is all we have that's reliable over long time periods and how
| we'd deal with that. In principle sneakernetting around gigabytes
| or even terabytes of entropy securely and a hardware and software
| stack that automatically takes care of the rough edges should be
| doable but I don't know of any projects that have even started
| around that idea.
|
| PQE is obviously the best outcome, we ""just"" switch albeit with
| a lot of increase compute and changed assumptions in protocols
| pain, but we're necessarily going to be leaning on a lot of new
| math and systems that won't have had the tires kicked nearly as
| long as all conventional ones have. I guess it's all feeling real
| now.
| scorpionfeet wrote:
| This is exactly how customers who do threat modeling see PQC. HN
| can armchair QB this all they want, the real money is moving fast
| to migrate.
|
| The analogy to a small atomic bomb is on point.
| aborsy wrote:
| I don't know why the author likes AES 128 so badly. AES 256 adds
| little additional cost, and protects against store now decrypt
| later attacks (and situations like: "my opinion suddenly changed
| in few months"). The industry standard and general recommendation
| for quantum resistant symmetric encryption is using 256 bit keys,
| so just follow that. Every time he comes up with all sorts of
| arguments that AES 128 is good.
|
| Age should be using 256 bit file keys, and default to PC keys in
| asymmetric mode.
| cwmma wrote:
| he pretty explicitly states that AES 128 is not in any imminent
| danger and mandating a switch to 256 would distract from the
| actual thing he thinks needs to happen.
| aborsy wrote:
| How would he know? Did he publish papers on it?
|
| You can't just throw "Grover's algorithm is difficult to
| parallelize" etc. It's not same as implementation, especially
| when it gets to quantum computers. It's very specialized.
| lucb1e wrote:
| So why argue about whether AES-256 is worth it if we can just
| literally replace those 3 characters and be done with the
| upgrade? This was the smart move already in 2001 when Shor's
| algorithm was known and computers fast enough that we don't
| notice the difference. At least to me, it seems like less
| bikeshedding will be done if we abandon AES-128 and don't
| have to deal with all the people left wondering if that's
| truly ok
|
| Then again, something something md5. 'Just replace those
| bytes with sha256()' is apparently also hard. But it's a lot
| easier than digging into different scenarios under which md5
| might still be fine and accepting that use-case, even if only
| for new deployments
| tptacek wrote:
| Because you cannot "just literally replace those 3
| characters and be done with the upgrade".
| FiloSottile wrote:
| > The industry standard and general recommendation for quantum
| resistant symmetric encryption is using 256 bit keys
|
| It simply is not. NIST and BSI specifically recommend all of
| AES-128, AES-196, and AES-256 in their post-quantum guidance.
| All of my industry peers I have discussed this with agree that
| AES-128 is fine for post-quantum security. It's a LinkedIn meme
| at best, and a harmful one at that.
|
| My opinion changed on the _timeline_ of CRQC. There is no
| timeline in which CRQC are theorized to become a threat to
| symmetric encryption.
| kro wrote:
| The argument to skip hybrid keys sounds dangerous to me. These
| algorithms are not widely deployed and thus real world tested at
| all. If there is a simple flaw, suddenly any cheap crawler pwns
| you while you tried to protect against state actors.
| kro wrote:
| I wonder, what is the impact of this to widely deployed
| smartcards like credit cards / EID passports?
|
| Aren't they relying on asymmetrical signing aswell?
| lucb1e wrote:
| Yes. They will need to switch, so that hardware needs to be
| swapped out
| commandersaki wrote:
| RemindMe! 3 years "impending doom"
| griffzhowl wrote:
| noob question: can't we just use longer classical keys, at least
| as a stop gap?
| adgjlsfhk1 wrote:
| They're a pretty bad stopgap:
| https://bas.westerbaan.name/notes/2026/04/02/factoring.html.
| Going to RSA-32000 only buys you ~a year once QCs can factor
| RSA-2048. In order to get a standard that would resist quantum
| attacks for realistic time, we would need MB to GB keys at
| least (see https://eprint.iacr.org/2017/351.pdf for a hilarious
| post-quantum RSA attempt that used terabyte size keys)
| oncallthrow wrote:
| No, and even if we could, it would require a migration of
| approaching the same difficulty of a migration to PQ, at which
| point why not just migrate to PQ
| upofadown wrote:
| So this is the exciting paper:
|
| * https://arxiv.org/pdf/2603.28627
|
| The new thing here seems to be the use of the neutral atom
| technique. Supposedly we are up to 96 entangled qubits for a
| second or two based on neutral atoms.
|
| Shouldn't that be enough capability to factor 15 using Shor's?
| codethief wrote:
| > Trusted Execution Environments (TEEs) like Intel SGX and AMD
| SEV-SNP and in general hardware attestation are just f*d. All
| their keys and roots are not PQ and I heard of no progress in
| rolling out PQ ones, which at hardware speeds means we are forced
| to accept they might not make it, and can't be relied upon.
|
| Slightly off-topic but: Does anyone know what the Signal
| developers plan on doing there to replace SGX? I mean it's not
| like outside observers haven't been looking very critically at
| SGX usage in Signal for years (which the Signal devs have
| ignored), but this does seem to put additional pressure on them.
| tptacek wrote:
| Signal uses SGX for features every other mainstream E2E
| messenger does in serverside plaintext.
| nodesocket wrote:
| The first and most obvious target will be Bitcoin. It's market
| cap today is $1.4T. That's a gigantic reward for any state actor
| or entity with the resources and budget to break it.
|
| Does this mean Bitcoin is going to $0? Absolutely not, it's just
| going to take the community organizing and putting in the
| gigantic effort to make the changes. Frankly I'm not personally
| clear if that means all existing cold wallets need to be
| flashed/replaced? All existing Bitcoin miner software needs to be
| updated? All existing Bitcoin node software needs to be updated?
| btdmaster wrote:
| > "Doesn't the NSA lie to break our encryption?" No, the NSA has
| never intentionally jeopardized US national security with a non-
| NOBUS backdoor, and there is no way for ML-KEM and ML-DSA to hide
| a NOBUS backdoor.
|
| The most concrete issue for me, as highlighted by djb, is that
| when the NSA insists against hybrids, vendors like
| telecommunications companies will handwrite poor implementations
| of ML-KEM to save memory/CPU time etc. for their constrained
| hardware that will have stacks of timing side channels for the
| NSA to break. Meanwhile X25519 has standard implementations that
| don't have such issues already deployed, which the NSA presumably
| cannot break (without spending $millions per key with a
| hypothetical quantum attack, a lot more expensive than side
| channels).
| Avamander wrote:
| > The most concrete issue for me, as highlighted by djb, is
| that when the NSA insists against hybrids
|
| The fact that only NSA does that and they really have no
| convincing arguments seems like the biggest reason why the
| wider internet should only roll out hybrids. Then possibly wait
| decades for everything to mature and then reconsider plain
| modes of operation.
| FiloSottile wrote:
| Thus succeeding at making the telecommunications vendors used
| for Top Secret US national security data less secure, the
| _obvious_ goal of the US National Security Agency, and the only
| reason they wouldn 't use the better cryptography designed by
| Dr. Bernstein. /s
|
| Truly, truly can't understand why anyone finds this line of
| reasoning plausible. (Before anyone yells Dual_EC_DRBG, that
| was a NOBUS backdoor, which is an argument _against_ the NSA
| promoting mathematically broken cryptography, if anything.)
|
| Timing side channels don't matter to ephemeral ML-KEM key
| exchanges, by the way. It's _really hard_ to implement ML-KEM
| wrong. It 's _way easier_ to implement ECDH wrong, and remember
| that in this hypothetical you need to compare to P-256, not
| X25519, because US regulation compliance is the premise.
|
| (I also think these days P-256 is fine, but that is a different
| argument.)
___________________________________________________________________
(page generated 2026-04-06 23:00 UTC)