A Post-Quantum Future for Let's Encrypt
Let's Encrypt plans to adopt Merkle Tree Certificates to enable post-quantum cryptography without bloating TLS handshakes.
Let's Encrypt announced plans to support Merkle Tree Certificates (MTCs) as its path to post-quantum security. MTCs batch certificate issuance under a single signature, reducing handshake size despite using larger post-quantum algorithms like ML-DSA-44. A typical MTC handshake contains one signature, one public key, and one inclusion proof, smaller than today's Web PKI despite post-quantum algorithms. Traditional post-quantum signatures (2,420 bytes for ML-DSA-44 vs. 64 bytes for ECDSA-P256) would bloat handshakes past 10 kilobytes, causing real-world connection failures. MTCs also embed Certificate Transparency natively rather than bolting it on post-issuance. Let's Encrypt targets late 2026 for a staging environment and 2027 for production. This work requires changes across issuance infrastructure, the ACME protocol, and transparency logs.
The timeline has accelerated. Google and Cloudflare committed to post-quantum migration by 2029. The NSA, NIST, and EU all target 2030-2035 for broad adoption. PLANTS working group and Chrome are already experimenting with MTCs. Current Let's Encrypt certificates remain unchanged; post-quantum support will be free and automated when available.
What HN community is saying
Commenters questioned whether post-quantum algorithms can be proven secure without knowing future quantum capabilities. Responses clarified that quantum computing's theoretical capabilities are well-understood mathematically independent of physical quantum computer progress, similar to how classical cryptography's hardness assumptions rest on unproven mathematical conjectures. One correction: encrypting data twice with different algorithms does not provide hybrid security; proper hybrid schemes use a Hybrid KEM instead. A concrete note surfaced that post-quantum encryption (for protecting against future decryption) is more urgent than authentication, making server-side deployment of X25519MLKEM768 a high-leverage priority this year.