Google's Quantum-Safe HTTPS: How Merkle Trees Will Keep the Web Secure

Google and Cloudflare are deploying Merkle Tree Certificates to protect HTTPS against quantum computer attacks without breaking the internet

Quantum computers will eventually break the cryptography that secures virtually all internet traffic. Google’s solution: stop signing certificates individually and start using clever math to squeeze 15 kilobytes of quantum-resistant data into roughly 700 bytes.

The company announced its Chrome Quantum-resistant Root Store initiative, with Merkle Tree Certificates (MTCs) at its core. The system is already live-testing with Cloudflare, processing about 1,000 certificates through the new infrastructure.

The Quantum Problem

Post-quantum cryptographic algorithms like ML-DSA generate signatures and keys that are dramatically larger than their classical counterparts. An ML-DSA-44 signature takes up 2,420 bytes compared to just 64 bytes for ECDSA-P256 - a 38-fold increase.

That matters because every HTTPS connection requires multiple signatures. The current system needs approximately five signatures and two public keys per handshake to authenticate a server and verify it through the certificate chain and Certificate Transparency logs.

Simply swapping in quantum-resistant algorithms would balloon certificate sizes from around 384 bytes to over 20,000 bytes. According to Tweede golf’s analysis, adding 9KB slows connections by about 15%. Cross the 10KB boundary and you’re looking at an extra network round trip, potentially slowing connections by more than 60%.

Google isn’t willing to break the web to save it.

How Merkle Trees Fix This

The insight behind MTCs is simple: instead of signing every certificate individually, sign a single tree containing millions of certificates.

Here’s how it works:

  1. A Certification Authority collects certificates into batches
  2. Each certificate is hashed and arranged into a tree structure
  3. Pairs of hashes are recursively combined until reaching a single root hash (the “Tree Head”)
  4. The CA signs only this root - one signature for potentially millions of certificates
  5. Each certificate gets an “inclusion proof” showing it’s part of the signed tree

The inclusion proof is just the sequence of hashes needed to reconstruct the path from your certificate to the signed root. Change anything in the certificate and the proof fails.

According to Cloudflare’s technical breakdown, this reduces handshake components to one signature, one public key, and one inclusion proof. If landmarks (trusted tree roots) are allocated hourly, the inclusion proof runs about 736 bytes - smaller than a single ML-DSA signature.

Why This Actually Makes Things Faster

Counter-intuitively, quantum-resistant MTCs may actually improve performance over today’s non-quantum certificates.

Current HTTPS requires verifying multiple signatures per connection. MTCs eliminate most of that cryptographic overhead. Browsers receive updated landmarks offline, so they don’t need to verify signatures during the handshake itself - just check that the inclusion proof leads to a trusted root.

Cloudflare expects latency to decrease despite the switch to post-quantum algorithms. They report that roughly 50% of traffic to their edge network is already protected against “harvest now, decrypt later” attacks through post-quantum key exchange. MTCs address the remaining authentication gap.

The Rollout Timeline

Google and Cloudflare are taking a cautious three-phase approach:

Phase 1 (Current): Chrome and Cloudflare run feasibility studies. All MTC connections are backed by traditional X.509 certificates as a failsafe. Early 2026 sees rollout to a subset of Cloudflare customers.

Phase 2 (Q1 2027): Certificate Transparency log operators join the ecosystem. Any operator with usable logs before February 1, 2026 can begin bootstrapping public MTCs.

Phase 3 (Q3 2027): Launch of the Chrome Quantum-resistant Root Store (CQRS), accepting new MTC-only Certificate Authorities alongside the existing Chrome Root Program.

The certificates themselves have roughly one-week lifetimes - much shorter than traditional certificates but appropriate for a system designed around frequent batch updates.

What’s Being Tested

Google and Cloudflare are investigating several open questions:

  • Protocol compatibility: Will middleboxes, proxies, and enterprise security appliances break when they encounter MTCs?
  • Client update frequency: How often do devices actually fetch new landmarks?
  • Fallback behavior: When clients lack recent landmarks, larger certificates must be issued

The bootstrap phase uses a clever trick: Cloudflare “re-encodes” existing trusted CA certificates as MTCs. For each MTC issued, a corresponding certificate from an established CA is published and verified through Certificate Transparency before landmarks reach Chrome users.

Why You Should Care

Quantum computers capable of breaking current encryption don’t exist yet. The most optimistic estimates put them years away; pessimistic estimates say decades.

But “harvest now, decrypt later” attacks are already happening. Adversaries can record encrypted traffic today and wait for quantum computers to crack it later. Anything sensitive enough to matter in ten or twenty years - medical records, financial data, government communications - is already at risk.

Google’s MTC approach means the web can transition to quantum resistance without a performance apocalypse. The alternative - simply bolting enormous post-quantum signatures onto the existing certificate system - would either dramatically slow the internet or force a years-long transition period where quantum-vulnerable connections remain common.

The Bottom Line

Google and Cloudflare have found a way to make quantum-safe HTTPS faster than today’s non-quantum version. The system is already in testing with real traffic, with broader deployment planned for 2027. For most users, the transition should be invisible - which is exactly what good security infrastructure should be.