HN Debrief

A Post-Quantum Future for Let's Encrypt

  • Security
  • Infrastructure
  • Cryptography
  • Open Source

Let's Encrypt's post lays out a plan for surviving post-quantum cryptography's ugly practical problem: signatures like ML-DSA are much bigger than RSA or elliptic-curve signatures, so naively swapping them into the web PKI would bloat TLS handshakes. The proposed answer is Merkle Tree Certificates, where certificates live inside a published Merkle tree and clients validate them with a short inclusion proof plus a small amount of cached state called landmarks. That folds certificate transparency into issuance itself instead of bolting it on afterward, and in the common case it can make a post-quantum handshake smaller than today's certificate path.

If you run internet-facing infrastructure, assume post-quantum migration is no longer just a research topic. Start by checking whether your TLS stack, certificate tooling, embedded clients, and code-signing path can handle larger artifacts, out-of-band trust updates, and a multi-year transition rather than a simple cipher swap.

Discussion mood

Mostly positive and serious. People liked the technical direction and the chance to fix long-standing PKI and certificate transparency problems, but they were wary about deployment complexity, landmark distribution, embedded support, and the still-messy state of post-quantum signatures.

Key insights

  1. 01

    Landmark distribution becomes the real platform problem

    Keeping handshakes small depends on clients already having recent landmarks, which moves complexity out of TLS and into an update channel every platform has to operate. Browsers can probably piggyback on existing vendor infrastructure, but general-purpose clients and embedded systems do not have an obvious operator, so the elegant crypto design turns into an OS distribution and device lifecycle problem.

    Treat MTC support as a trust-state distribution project, not just a certificate format change. If you own clients outside major browsers, plan now for how landmark data will be fetched, cached, shared system-wide, and kept fresh on intermittently connected devices.

      Attribution:
    • agwa #1
    • mcpherrinm #1
    • crote #1
    • Cyfrit #1
  2. 02

    MTC is also a cleanup of Certificate Transparency

    The appeal is bigger than post-quantum size savings. MTC removes SCTs as an awkward afterthought, bakes inclusion proofs into the certificate itself, and adds witness cosigning so a CA cannot cheaply show one client a forked log without involving witnesses too. That makes independent verification simpler and pushes the ecosystem closer to transparency by construction rather than transparency by convention.

    If you care about certificate issuance integrity, evaluate MTC on CT simplification merits as well as PQ readiness. It may reduce whole classes of monitoring and split-view headaches even before quantum timelines are settled.

      Attribution:
    • mcpherrinm #1 #2
  3. 03

    Hybrid works for key exchange, not as a vague 'encrypt twice' idea

    Several comments corrected the common mental model here. The practical post-quantum migration path for confidentiality is combining classical and PQ key establishment into one shared secret, then doing ordinary symmetric encryption once. That is very different from layering bulk encryption or casually nesting algorithms, and the distinction matters because current protocols use KEMs and combiners, not "double encryption" in the naive sense.

    When vendors or engineers say "hybrid," ask exactly what is being combined. For transport security, the safe default is a hybrid KEM or combiner feeding one AEAD session, not bespoke double-encryption schemes.

      Attribution:
    • mswphd #1 #2
    • 3form #1
    • some_furry #1 #2
  4. 04

    Signature migration is slow even if quantum cracking stays hidden

    The most forceful pushback in the comments was against the lazy line that only harvest-now-decrypt-later matters. Certificate chains, firmware signing, secure boot, hardware tokens, and identity systems have long replacement cycles and often require physical or organizational rollout, so reactive migration is fantasy. Even in Web PKI, the trigger for "quantum is here" may not announce itself cleanly. A forged signature can look like key theft or an implementation bug.

    Inventory long-lived signing roots and verification paths now. The hard part is not proving a quantum threat date, it is shortening the time your organization would need to rotate trust anchors and deploy new verifiers across legacy systems.

      Attribution:
    • skmurphy #1
    • some_furry #1
    • tomgag #1
    • buu700 #1
    • thyristan #1
  5. 05

    New certs will likely ship in two tiers

    Let's Encrypt staff clarified an operational detail missing from the high-level post. Fresh issuance can still happen quickly with a large standalone certificate, while the compact landmark-relative certificate arrives on the next landmark cadence, likely hourly for short-lived certs and slower for longer-lived ones. That means availability should not hinge on the compact path, but performance and elegance will.

    Design for a mixed mode where first issuance or stale clients may see materially larger certificates. If handshake size matters to your workload, measure the fallback path rather than assuming the compact form is universal from day one.

      Attribution:
    • mcpherrinm #1
    • agwa #1

Against the grain

  1. 01

    Authentication may matter more than secrecy for many systems

    A credible minority argued that harvest-now-decrypt-later is overemphasized outside intelligence and long-retention use cases. Plenty of TLS-protected traffic has little value after minutes or days, while signatures and trust anchors on firmware, vehicles, industrial gear, identity tokens, and embedded devices can stay in the field for decades. In that world, the harder business problem is not preserving old confidentiality but replacing who gets trusted to sign updates and identities.

    Do not let a TLS-centric threat model set all of your priorities. If you ship devices or signed artifacts, put code signing, secure boot, and verifier update paths on the same roadmap as transport encryption.

      Attribution:
    • JoachimS #1 #2 #3
    • raphinou #1
  2. 02

    Assuming secret NSA breaks in PQ schemes is weak reasoning

    One comment pushed back hard on the reflexive claim that the NSA must already know hidden flaws in the new lattice-based standards. The argument was that the agency historically favors vulnerabilities that are usable by them but not by everyone else, and there is no visible sign of that kind of backdoor in ML-KEM or ML-DSA. The public cryptanalysis community for lattices is also concentrated outside the obvious US government talent pipeline, which weakens the conspiracy framing.

    Be skeptical of blanket claims that standardized PQ algorithms are probably backdoored. You should still use conservative deployment patterns, but base risk decisions on concrete cryptanalysis and implementation quality, not institutional vibes.

      Attribution:
    • mswphd #1
  3. 03

    Quantum timelines are still uncertain enough to resist panic

    Not everyone accepted the near-term urgency. Some pointed to long-running skepticism about practical quantum computing, while another noted that anything capable of running Shor's algorithm at useful scale may still require a fundamental breakthrough, which puts the timeline anywhere from imminent to never. Even supporters of migration often framed current work as cheap insurance rather than proof that Q-day is close.

    Move on post-quantum readiness because large infrastructure changes are slow, not because anyone can promise a date. That supports phased migration and low-regret hybrids over crash programs built on a single timeline forecast.

      Attribution:
    • mswphd #1
    • bawolff #1
    • upofadown #1

In plain english

aes ↩
In ggplot-style plotting, short for aesthetic mappings, which connect data fields to visual properties like position, color, or size.
CA ↩
Certificate Authority, an entity that signs TLS certificates so clients can trust them.
Certificate Transparency ↩
A system of public logs for issued TLS certificates, meant to make misissued certificates visible and auditable.
curl ↩
A common command-line tool and library used to transfer data over network protocols like HTTP.
elliptic-curve cryptography ↩
A family of public-key cryptographic systems based on arithmetic on elliptic curves, often used for modern TLS and SSH.
embedded systems ↩
Computers built into devices like appliances, sensors, vehicles, and industrial equipment, often with limited memory and infrequent updates.
firmware ↩
Software stored inside a device that directly controls how its hardware operates.
landmarks ↩
Cached trust state in the MTC design that lets clients validate compact certificates relative to a known checkpoint.
Merkle tree ↩
A tree of hashes that lets you prove a specific item is part of a larger set without sending the whole set.
Merkle Tree Certificates ↩
A proposed certificate format where certificates are included in a Merkle tree so clients can verify them with compact proofs instead of large certificate chains.
ML-DSA ↩
Module-Lattice Digital Signature Algorithm, a standardized post-quantum digital signature scheme derived from lattice cryptography.
ML-KEM ↩
Module-Lattice Key Encapsulation Mechanism, a standardized post-quantum key establishment scheme based on lattice problems.
post-quantum cryptography ↩
Cryptographic algorithms designed to resist attacks from quantum computers as well as ordinary computers.
RSA ↩
Rivest-Shamir-Adleman, a widely used public-key cryptography algorithm.
Secure Boot ↩
A boot security feature that only allows software signed by trusted keys to run during startup.
TLS ↩
Transport Layer Security, the standard protocol used to encrypt network connections such as web traffic or mail transport.
Web PKI ↩
Web Public Key Infrastructure, the global trust system of certificate authorities, browser trust stores, and rules used to validate HTTPS certificates.

Reference links

Reference material on post-quantum migration

MTC and transparency infrastructure

  • rustls upki
    Suggested as a possible shared mechanism for landmark distribution on Linux and other non-browser clients
  • Cordon
    An implementation of a Merkle Tree Certificates compliant CA and ACME server mentioned as a practical reference
  • Verifiable indexes talk
    Shared as an introduction to verifiable indexes for monitoring certificate logs more efficiently
  • transparency-dev vindex incubator
    Code and design reference for verifiable indexes, which were mentioned as a future improvement for monitoring logs

PQ cryptography explainers and standards

Quantum risk skepticism and background