Google’s Merkle Tree Certificates: A practical bridge to quantum‑safe HTTPS

Background

Quantum computing changes the threat model for the internet’s identity and encryption systems. Today’s HTTPS relies on two main cryptographic pillars:

• Key agreement for confidentiality (e.g., X25519 or P‑256 ECDH) so that only the browser and server can read traffic.
• Digital signatures for authentication (e.g., RSA or ECDSA) so the browser knows it’s really talking to, say, example.com.

A large, fault‑tolerant quantum computer would endanger both. Shor’s algorithm could break RSA and ECDSA, undermining certificate signatures and server authentication, while also breaking classical key exchange. That’s why standards bodies and vendors are moving to post‑quantum cryptography (PQC): new algorithms designed to resist quantum attacks.

• For key exchange, the industry has started deploying post‑quantum key encapsulation (KEM) such as Kyber (standardized as ML‑KEM). Chrome, major CDNs, and others have already trialed hybrid key exchanges that combine classical ECDH with Kyber to protect against “harvest now, decrypt later.”
• For authentication (the signatures used in certificates and in the TLS handshake), the transition is harder. PQ signature algorithms like Dilithium (ML‑DSA) or SPHINCS+ have larger keys and signatures, and the web PKI is vast: browsers, operating systems, certificate authorities (CAs), enterprise middleboxes, and devices must all agree on formats, sizes, and validation rules.

The result: we need a migration path that adds post‑quantum authentication without breaking legacy clients or exploding certificate sizes. Enter Merkle Tree Certificates.

What happened

Google has added support in Chrome for verifying a new X.509 extension informally known as a Merkle Tree Certificate (MTC). The idea is deceptively simple and relies on classic, well‑understood math: Merkle trees (hash trees).

• A Merkle tree lets you commit to a large set of values by publishing a single hash (the root). To prove any individual value is in the committed set, you send just that value plus a short “authentication path” of sibling hashes. The verifier recomputes the root and checks it matches the commitment.

Applied to HTTPS certificates, that becomes a powerful compatibility mechanism:

• The certificate embeds a Merkle root that commits to multiple alternative authentication options: for example, a classical ECDSA path, a post‑quantum Dilithium path, perhaps even future algorithms.
• During the TLS handshake, the server chooses an authentication option compatible with the client’s capabilities (which the client advertises via TLS’s signature_algorithms and related extensions).
• The server then presents only the relevant signature (e.g., a Dilithium signature over the handshake transcript) plus a compact Merkle proof showing that this signature/key was pre‑committed in the certificate the CA signed.
• Old clients that know nothing about Merkle proofs just follow the classical path they already understand. New clients verify the Merkle proof and the PQ signature, achieving quantum‑resistant authentication—without downloading multiple full signatures or parallel certificate chains.

This makes MTCs a migration bridge:

• Compatibility: The CA still issues a normal, PKI‑compliant certificate. Legacy clients validate it as usual.
• Agility: Modern clients can opt into PQ authentication immediately, provided the server and certificate include the necessary leaves in the Merkle tree.
• Efficiency: Instead of shipping multiple complete signatures (potentially kilobytes each) for every step in the chain, the server ships a single chosen signature plus a logarithmic‑size proof (a few dozen bytes per tree level). That keeps handshake sizes and latency in check.

Google’s move means Chrome can understand and enforce these proofs today. With one major engine on board, other browsers, TLS libraries, and CAs have a clear target for interoperability.

How Merkle Tree Certificates work (conceptual deep dive)

At a high level:

1. The site operator prepares a set of authentication options (leaves). Each leaf binds a specific algorithm and public key to the same identity (e.g., example.com) and usage. For example:
   • Leaf A: ECDSA P‑256 public key for TLS server auth
   • Leaf B: ML‑DSA (Dilithium‑2) public key for TLS server auth
   • Leaf C: Future algorithm placeholder or a different curve
2. The leaves are hashed and arranged into a Merkle tree. The root hash becomes a compact commitment to all included options.
3. The CA issues a normal X.509 certificate but includes a new extension that carries this Merkle root (and necessary metadata). The CA signs the certificate as usual (today that’s typically ECDSA or RSA). Certificate Transparency logging, OCSP, and CRLs continue to work unchanged because the certificate is still an ordinary X.509 object with an extra extension.
4. During a TLS handshake:
   • The client advertises supported signature algorithms.
   • The server picks an algorithm that both sides support. If the client supports a PQ signature (e.g., Dilithium), the server can choose it.
   • The server sends the certificate (with the Merkle root) plus:
     • The algorithm‑specific public key and signature over the TLS handshake transcript.
     • A Merkle proof (the sibling hashes) that show this key belonged to the committed set.
   • A PQ‑aware client verifies (a) the CA‑signed certificate, (b) the Merkle proof linking the chosen key back to the committed root in the cert, and (c) the chosen algorithm’s signature over the handshake transcript.

The security intuition:

• Legacy clients still rely on classical PKI signatures and behavior.
• PQ‑aware clients are not limited by the CA’s signature algorithm choice; they get end‑to‑end post‑quantum authentication of the actual TLS session they are establishing.
• If a future quantum adversary can forge classical CA signatures, that doesn’t let them impersonate to PQ‑aware clients unless they can also forge the PQ signature used within the session—and that’s the point of introducing PQ algorithms.

Why Merkle trees?

• Size: PQ signatures can be big. Dilithium‑2 signatures are about 2.4 KB; SPHINCS+ can be 8–30+ KB depending on parameters. Shipping multiple of those per handshake is costly. A Merkle proof, by contrast, is just one hash per tree level—tens to a few hundred bytes total—so you only pay for the one signature you actually need.
• Simplicity: Merkle trees rely on hash functions. Hashes remain relatively robust even against quantum adversaries (Grover’s algorithm offers only a quadratic speedup), so with conservative parameters (e.g., SHA‑256/384) the construction is well‑understood and conservative.
• Agility: Need to add a new algorithm? You can include it in a future certificate issuance without breaking old clients, while new clients start using it immediately.

What this is—and isn’t

It’s tempting to call this “quantum‑proof HTTPS,” but precision matters:

• MTCs enable quantum‑resistant authentication for clients and servers that participate. Combined with PQ key exchange (e.g., ML‑KEM/Kyber), the resulting session is protected against harvest‑now‑decrypt‑later and against future active attackers who lack the PQ private key.
• However, the CA’s signature on the certificate itself may remain classical during the transition, because that’s what the whole ecosystem supports today. That’s acceptable for a migration period, especially since authentication signatures inside TLS are per‑session and cannot be retroactively forged on old captures.
• Long term, the ecosystem is still moving toward full PQ certificates—CAs signing with PQ algorithms too. MTCs are the bridge that gets us there without breaking anything in the meantime.

Why this matters for the web

• Speed of adoption: Servers can ship a single certificate that works for everyone. New clients get PQ; old clients remain happy. That removes a big deployment barrier.
• Smaller handshakes than naïve "dual" certificates: Without MTCs, you might have to present parallel chains or add multiple heavy PQ signatures. MTCs trim that overhead to nearly the cost of one signature plus a compact proof.
• Operational continuity: CT logs, revocation, compliance audits, and monitoring continue unchanged. CAs do not need to switch their internal HSMs or processes to PQ on day one to enable PQ session authentication for clients.
• Algorithm agility: The next time cryptography needs to pivot—whether due to quantum or classical cryptanalysis—this pattern reduces friction.

Key takeaways

• Chrome understands and verifies Merkle Tree Certificates, a new X.509 extension that commits to multiple authentication options via a hash tree.
• Servers can present a post‑quantum signature and a short Merkle proof to PQ‑aware clients, while legacy clients keep using classical authentication.
• MTCs reduce handshake bloat versus shipping multiple signatures or parallel chains, which is crucial because PQ signatures are larger.
• This is a migration bridge: it raises the security floor today without requiring an overnight switch to PQ at CAs and OS trust stores.
• The approach is standards‑friendly, keeps Certificate Transparency and revocation unchanged, and preserves wire compatibility with existing middleboxes.

What to watch next

• Broader browser support: With Chrome implementing verification, expect other engines (Safari, Firefox) and mobile platforms to evaluate and, potentially, adopt compatible behavior.
• TLS library updates: BoringSSL, OpenSSL, NSS, and platform stacks like SChannel and Secure Transport will need to parse, validate, and expose the MTC extension and verify Merkle proofs.
• CA readiness: Commercial and free CAs must support issuing certificates with the MTC extension, tooling for requesters to build trees, and ACME automation for multi‑algorithm requests.
• PQ signature choices: Dilithium (ML‑DSA) is the front‑runner; SPHINCS+ offers conservative hash‑based assurances but larger sizes; Falcon is compact but challenging to implement side‑channel‑resistant. Expect experimentation and policy debates.
• Policy and baseline requirements: CA/Browser Forum guidelines will likely evolve to codify how MTCs are formed, what OIDs and parameters are allowed, and how audit/compliance treats multi‑algorithm commitments.
• Performance and telemetry: Browsers and CDNs will measure handshake sizes, CPU cost of verifying PQ signatures and Merkle proofs, and failure modes across the long tail of devices and networks.
• Full PQ certificates: As PQ algorithms make their way into HSMs and FIPS validations, watch for CAs to begin signing intermediates and roots with PQ schemes, ultimately making the entire chain quantum‑resistant.

Practical considerations and trade‑offs

• Size vs. flexibility: Each additional algorithm included in the tree adds minimal proof overhead but still requires the server to host the corresponding key and produce signatures. Operationally, start with one classical and one PQ choice.
• Hash function strength: Because Merkle trees rely on collision resistance, use conservative hash choices (e.g., SHA‑256 or SHA‑384). If you expect very long lifetimes or high stakes, SHA‑384 further cushions against quantum speedups.
• Key management: You’re effectively managing multiple authentication keys for the same identity. Integrate with HSMs and key rotation policies to avoid sprawl.
• Monitoring and CT: Security teams should update certificate inventory systems to parse the MTC extension and track which algorithms are committed for which domains.
• Interop testing: Staged rollouts with canaries and A/B tests will help identify edge devices or middleboxes that mishandle new certificate extensions or larger handshake messages.

A quick mental model: without and with MTCs

• Without MTCs

  • To offer both classical and PQ authentication, you might ship two separate certificates or a certificate with multiple signatures. Handshakes get heavier, middleboxes might choke, and CT/revocation complexity grows.

• With MTCs

  • You ship one ordinary certificate that quietly commits to several authentication options. At runtime, you deliver only the one your peer can use, plus a few sibling hashes. Everyone gets what they can handle; no one downloads what they can’t use.

Short FAQ

• Does this instantly make the web quantum‑safe?

  • No. It enables quantum‑resistant authentication for participating clients and servers. Full quantum safety also depends on PQ key exchange (already underway) and, eventually, PQ‑signed CA certificates.

• Why not just wait until CAs can sign with PQ algorithms?

  • Because clients and servers can benefit from PQ authentication now, and MTCs let us deliver that without breaking legacy clients or rewriting the PKI overnight.

• Won’t this break old devices or middleboxes?

  • The X.509 extension is designed to be ignored by unaware clients. Handshake behavior remains legal TLS. As always, broad testing is prudent, but the design aims for wire compatibility.

• Are Merkle proofs secure against quantum attacks?

  • Merkle trees rely on hash functions. Quantum speedups against hashes are limited; using sufficiently strong hashes (e.g., SHA‑256/384) preserves conservative security margins.

• Which PQ signatures will browsers accept?

  • Policies vary and will evolve. Expect ML‑DSA (Dilithium) to be among the first, with others like SPHINCS+ evaluated as implementations mature and performance data accumulates.

• Do I need a new CA or special CT logs?

  • No. The certificate is still a normal X.509 artifact with an additional extension. CT logging and revocation processes continue as before.

• What’s the cost in bytes?

  • A Merkle proof adds roughly one hash per tree level—on the order of tens to a few hundred bytes—far smaller than shipping multiple complete signatures or duplicate chains.

Bottom line

Merkle Tree Certificates are a clever, conservative use of hash trees to make the post‑quantum authentication transition practical. They preserve compatibility, reduce bandwidth, and let security improve as fast as clients and servers are ready—without waiting for the entire PKI to flip a switch. Chrome’s support is a strong signal that this approach is moving from research to reality, and it sets the stage for a smoother, safer upgrade of the web’s identity layer.

Source & original reading: https://arstechnica.com/security/2026/02/google-is-using-clever-math-to-quantum-proof-https-certificates/