As the maintainer of Go's standard library crypto packages, Valsorda reframes the quantum timeline debate from a practitioner's perspective. He argues that whether CRQCs are 10 or 30 years away, the answer for engineering teams is similar — cryptographic migrations are slow, painful infrastructure projects that take years to execute, so action is needed regardless of the exact timeline.
By surfacing Valsorda's post (which earned 394 points and 158 comments), the HN community signaled strong appetite for quantum assessments from people who ship cryptographic code rather than quantum computing companies selling roadmaps, VCs hyping portfolios, or academics publishing for tenure. The implicit argument is that Valsorda's unique position maintaining crypto/tls and crypto/x509 makes his timeline assessment more trustworthy than those from parties with financial or reputational incent
The editorial synthesis argues that quantum computing discussion has been trapped between two unproductive poles: national security agencies and quantum companies warning of Q-Day by 2029-2030, and skeptics noting we've been '10 years away' for 30 years. Valsorda's practitioner-focused analysis is valuable precisely because it cuts through this binary by shifting the question to actionable engineering decisions.
Filippo Valsorda — the independent cryptography engineer who maintains Go's standard library crypto packages, previously on Google's Go security team — published a detailed assessment of timelines for cryptographically relevant quantum computers (CRQCs). The post landed on Hacker News and pulled 394 points, a strong signal that the developer community is hungry for quantum computing takes from people who actually ship cryptographic code rather than publish press releases.
Valsorda's perspective matters because he sits at an unusual intersection: he's not a quantum physicist selling a roadmap, not a VC hyping a portfolio company, and not an academic publishing for tenure. He's the person who has to decide, today, what goes into the cryptographic libraries that millions of Go programs depend on. When your day job is maintaining `crypto/tls` and `crypto/x509`, quantum timelines stop being theoretical and start being engineering decisions with real deadlines.
The quantum computing discourse has been stuck in a frustrating binary for years. On one side: quantum computing companies and national security agencies warning that Q-Day is imminent, sometimes with timelines as aggressive as 2029-2030. On the other: skeptics pointing out that we've been "10 years away" from useful quantum computers for roughly 30 years, and that the engineering challenges of scaling from hundreds of noisy qubits to the millions of error-corrected logical qubits needed to break RSA-2048 remain staggering.
What makes Valsorda's analysis valuable is that he approaches the question from the practitioner's side: not "when will CRQCs exist?" but "what should I be doing right now given the uncertainty?" This reframing cuts through the noise. Whether you believe CRQCs are 10 years out or 30, the answer for most engineering teams is surprisingly similar — because cryptographic migrations are slow, painful infrastructure projects that take years to execute.
Consider the precedent. The migration from SHA-1 to SHA-256 took roughly a decade of active effort across the industry, and SHA-1 wasn't even broken by an adversary — the theoretical attacks just got close enough that the risk became unacceptable. The migration from RSA/ECC to post-quantum algorithms like ML-KEM (formerly CRYSTALS-Kyber) and ML-DSA (formerly CRYSTALS-Dilithium) is substantially more complex. Key sizes are larger. Performance characteristics are different. Protocol interactions are more subtle. And unlike SHA-1→SHA-256, you can't do a simple drop-in replacement in many cases.
The Hacker News discussion reflected the community's sophisticated understanding of these trade-offs. Several commenters noted the "harvest now, decrypt later" threat model: adversaries (particularly nation-states) are already collecting encrypted traffic today with the intention of decrypting it once CRQCs become available. For any data that needs to remain confidential for 15+ years — government communications, medical records, long-term business secrets — the migration deadline isn't when CRQCs arrive, it's already passed.
NIST finalized its first set of post-quantum cryptography standards in 2024: ML-KEM for key encapsulation and ML-DSA for digital signatures. These aren't exotic research algorithms anymore — they're published standards with test vectors and reference implementations.
The real-world adoption picture is mixed but accelerating. Google Chrome and Cloudflare have been running hybrid post-quantum key exchange (X25519 + ML-KEM-768) in TLS since late 2023. Signal adopted the PQXDH protocol with ML-KEM. Apple's iMessage rolled out PQ3. AWS Key Management Service supports post-quantum TLS. But these are the well-funded vanguard. The vast majority of enterprise software, internal services, IoT devices, and embedded systems haven't begun the migration — and many don't even have an inventory of where cryptographic primitives are used.
This is the gap Valsorda's post highlights. The cryptographic community has done its job: the algorithms are standardized, the libraries are being updated, the protocols are being designed. The bottleneck has shifted entirely to deployment — getting post-quantum cryptography into the millions of systems that still rely exclusively on RSA and ECC.
If you're running a typical web service, here's the concrete state of play:
TLS/HTTPS: Modern browsers and CDNs already negotiate hybrid post-quantum key exchange if your server supports it. If you're using a recent version of Go (1.23+), BoringSSL, or OpenSSL 3.x with the right configuration, you may already be getting post-quantum protection for data in transit without realizing it. Check your TLS handshake — if you see `X25519Kyber768Draft00` or `X25519MLKEM768` in the key exchange, you're covered.
Data at rest: This is where most teams have more work to do. If you're encrypting data with AES-256, the symmetric side is already quantum-resistant (Grover's algorithm halves the effective key length, so AES-256 becomes AES-128-equivalent, which is still fine). The vulnerability is in how you manage and exchange the keys used for that encryption. Any RSA or ECC keys protecting your data-at-rest encryption keys need a migration plan.
Signatures and certificates: This is the hardest migration. Digital signatures touch everything: TLS certificates, code signing, package managers, JWTs, SSH keys, Git commits. The post-quantum signature schemes have significantly larger signatures and public keys (ML-DSA-65 signatures are ~3.3 KB vs. 64 bytes for Ed25519), which creates real performance and bandwidth concerns for protocols that weren't designed for that overhead.
The single most useful thing most teams can do today is conduct a cryptographic inventory: where are you using RSA and ECC, what are the key lifetimes, and which systems would be hardest to migrate? This isn't glamorous work, but it's the prerequisite for everything else.
The quantum timeline debate will continue, and that's fine. What shouldn't continue is using timeline uncertainty as an excuse for inaction. The cryptographic standards are ready. The first production deployments are running. The migration path is clear, if long. Valsorda's contribution is grounding this conversation in the reality of what it takes to actually change the cryptographic foundations of running systems — and reminding us that the people closest to the code are the ones we should be listening to about when to start. The answer, unsurprisingly, is now.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.