Valsorda reframes the CRQC debate away from predicting exact arrival dates and toward a more actionable question: how long does cryptographic migration actually take, and does your organization's timeline fit inside the remaining window? Having maintained Go's entire cryptography stack at Google, he has firsthand experience with how slow and complex real-world crypto migrations are.
The editorial argues that quantum computing companies and national security hawks push aggressive 5-10 year timelines to justify funding, while skeptics cite enormous engineering challenges to argue for decades. This noise has left most engineering organizations neither migrating nor planning to migrate, because the signal-to-noise ratio on timelines is abysmal.
Valsorda's assessment carries weight precisely because he is a working cryptography engineer whose incentives are aligned with getting the answer right, not with securing quantum computing funding or selling post-quantum migration products. His experience maintaining Go's crypto stack and building a professional open-source practice gives him both theoretical understanding and practical implementation perspective.
The editorial explicitly highlights the incentive alignment problem, noting this isn't an academic exercise from a physicist or a sales pitch from a quantum startup, but rather a threat assessment from someone who has personally shipped the code that would need to change in a post-quantum migration.
Filippo Valsorda — one of the most respected working cryptography engineers in the open-source ecosystem — published a detailed assessment of when cryptographically relevant quantum computers (CRQCs) will arrive. This isn't an academic exercise from a physicist or a sales pitch from a quantum startup. Valsorda maintained Go's entire cryptography stack at Google before leaving to build a professional open-source maintenance practice, making him one of the few people who both understands the theoretical threat and has personally shipped the code that would need to change.
The post, which hit 459 points on Hacker News, walks through the current state of quantum computing hardware, the gap between today's noisy intermediate-scale quantum (NISQ) machines and the fault-tolerant quantum computers needed to run Shor's algorithm at scale, and what that gap means for real-world migration planning. It's the kind of piece the industry needed: a threat assessment from someone whose incentives are aligned with getting the answer right rather than getting funding or selling post-quantum products.
The quantum computing timeline debate has been stuck in a frustrating loop for years. Quantum computing companies and national security hawks push aggressive timelines ("5-10 years") to justify funding and urgency. Skeptics point to the enormous engineering challenges — error correction overhead, qubit quality, the gap between logical and physical qubits — and argue we have decades. The result is that most engineering orgs have no actionable position: they're neither migrating nor planning to migrate, because the signal-to-noise ratio on timelines is abysmal.
What makes Valsorda's analysis different is the framing. Rather than trying to predict exactly when a CRQC arrives, the more useful question is: how long does cryptographic migration actually take, and does your organization's migration timeline fit inside the window before the threat materializes? This is the "harvest now, decrypt later" problem made concrete. Adversaries — particularly nation-states — are already collecting encrypted traffic with the expectation of decrypting it when quantum capability arrives. If your data has a secrecy requirement of 10+ years, the migration deadline isn't when CRQCs arrive. It's already passed.
The Hacker News discussion around the piece is telling. The top-voted comments aren't debating whether post-quantum migration is necessary — that argument is settled. The community has moved to implementation questions: which algorithms to adopt, how to handle hybrid key exchange, and whether the NIST standards (ML-KEM, ML-DSA, SLH-DSA finalized in August 2024) are mature enough for production deployment. This shift from "if" to "how" is arguably more significant than any specific timeline estimate.
There's also a pragmatic thread running through the discussion about organizational readiness. Cryptographic migrations are notoriously slow. The industry spent over a decade migrating from SHA-1 to SHA-256 — and that was a straightforward hash function swap with no protocol-level changes. Post-quantum migration involves larger key sizes (ML-KEM public keys are ~800 bytes vs. ~32 bytes for X25519), new protocol handshakes, and potential performance regressions that need testing across every TLS-speaking service in your infrastructure.
To break RSA-2048 or crack elliptic curve cryptography, you need a quantum computer running Shor's algorithm with roughly 4,000 logical qubits. The catch is the word "logical." Each logical qubit requires thousands of physical qubits for error correction, putting the real hardware requirement somewhere in the range of 4-20 million physical qubits depending on error rates and architecture.
Today's largest quantum processors are in the 1,000-1,500 physical qubit range (IBM's Condor hit 1,121 in late 2023, and various roadmaps project 10,000+ by 2030). The gap between where hardware is now and where it needs to be for cryptographic relevance is roughly 3-4 orders of magnitude — not in qubit count alone, but in qubit quality, connectivity, and error correction overhead simultaneously. That's not a gap that closes on a predictable schedule.
But here's what practitioners need to internalize: the uncertainty itself is the problem. A 15% chance of CRQCs arriving by 2035 might sound low, but if your migration takes 5-7 years to complete and you haven't started, you're already gambling on the optimistic end of a distribution you can't control.
The actionable advice hasn't changed, but the urgency framing has sharpened. If you're running any service that handles data with long-term confidentiality requirements (healthcare, financial, legal, government), you should already be evaluating post-quantum TLS. Chrome and Firefox have shipped hybrid key exchange (X25519+ML-KEM) by default. Cloudflare and AWS have enabled it on their edges. The ecosystem is further along than most backend teams realize.
For the average SaaS shop, the immediate action items are concrete:
1. Audit your cryptographic dependencies. Know which libraries you use, which algorithms they default to, and whether they support post-quantum options. Go 1.23+ includes ML-KEM. OpenSSL 3.x has experimental support. Most cloud KMS services are adding PQ options.
2. Test hybrid key exchange in staging. The "hybrid" approach (classical + post-quantum together) means you get post-quantum security without losing classical security if the new algorithms have undiscovered weaknesses. This is the consensus engineering approach: don't rip-and-replace, layer post-quantum on top of proven classical crypto.
3. Inventory your "harvest now, decrypt later" exposure. Which of your encrypted data streams would still be sensitive in 10-15 years? Those need priority migration.
4. Update your threat model documentation. Even if you're not migrating today, document your timeline assumptions and trigger conditions. "We'll migrate when X happens" is better than no plan, and it forces you to define what X actually is.
Valsorda's post is part of a broader pattern: the cryptography practitioner community is doing the work of translating quantum computing uncertainty into engineering decisions. The era of treating post-quantum migration as a future problem is over — not because CRQCs are imminent, but because cryptographic migrations are slow enough that 'eventually' and 'now' are closer together than most engineering roadmaps assume. The NIST standards are finalized, the major browsers and CDNs have shipped hybrid support, and the Go and Rust ecosystems have production-ready implementations. The tooling bottleneck has cleared. What remains is organizational will and the kind of methodical dependency auditing that nobody enjoys but everybody needs.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.