Google Bets on Merkle Trees to Future-Proof HTTPS Against Quantum Attacks
Google Bets on Merkle Trees to Future-Proof HTTPS Against Quantum Attacks
- Why Enterprise RAID Rebuilding Succeeds Where Consumer Arrays Fail?
- Linus Torvalds Rejects MMC Subsystem Updates for Linux 7.0: “Complete Garbage”
- The Man Who Maintained Sudo for 30 Years Now Struggles to Fund the Work That Powers Millions of Servers
- How Close Are Quantum Computers to Breaking RSA-2048?
- Why Windows 10 Users Are Flocking to Zorin OS 18 Instead of Linux Mint?
- How to Prevent Ransomware Infection Risks?
- What is the best alternative to Microsoft Office?
Google Bets on Merkle Trees to Future-Proof HTTPS Against Quantum Attacks
A new certificate format called Merkle Tree Certificates is being tested in Chrome alongside Cloudflare, aiming to keep TLS handshake data compact while deploying post-quantum cryptography — with a full rollout targeted for 2027.
Reported March 1, 2026 · Based on Google’s announcement of February 28, 2026
Google’s Chrome team has announced a significant initiative to protect HTTPS certificate infrastructure from future quantum computing threats — without the crippling performance costs that a straightforward approach would impose.
The program, detailed in a blog post published February 28, 2026, centers on a novel certificate format called Merkle Tree Certificates (MTCs), which is currently being tested in Chrome in a live experiment with Cloudflare.
The Quantum Threat to HTTPS
Every time a browser connects to a secure website, it verifies a chain of cryptographic certificates that prove the site is legitimate. Today’s certificates rely on elliptic curve (EC) cryptography — compact and fast, with public keys that are roughly 64 bytes in size. But that efficiency rests on mathematical problems that a sufficiently powerful quantum computer running Shor’s algorithm could eventually solve, potentially allowing an attacker to forge certificates and impersonate trusted websites.
To defend against this threat, cryptographers have developed post-quantum algorithms such as ML-DSA (standardized by the U.S. National Institute of Standards and Technology). The catch: these algorithms produce keys and signatures that are orders of magnitude larger than their classical equivalents. Directly embedding post-quantum cryptographic material into traditional X.509 certificates would balloon their size from the current ~64-byte footprint to approximately 2.5 kilobytes — a roughly 40-fold increase that would significantly slow TLS handshakes and increase bandwidth consumption for every web connection on Earth.
The Merkle Tree Solution
Google’s solution is to stop sending full certificates to browsers altogether. Instead, MTCs replace the traditional chain of individual signatures with a compact Merkle tree proof. In this model, a Certificate Authority (CA) signs a single “Tree Head” — a single cryptographic commitment representing potentially millions of certificates — using a post-quantum algorithm. When a browser connects to a site, it only receives a short proof that the site’s certificate is included in that signed tree.
This architecture decouples cryptographic strength from the amount of data sent during connection setup. Because only a compact inclusion proof travels over the network rather than the full quantum-resistant keys and signatures, the in-flight data stays close to today’s 64-byte size. The quantum-resistant computation happens once, at tree-signing time, rather than being repeated for every browser connection.
A significant side effect of this design is that certificate transparency becomes structurally mandatory rather than a bolt-on requirement. Under the MTC model, a certificate cannot exist unless it has been included in a publicly verifiable log — making it considerably harder for bad actors to issue forged or rogue certificates that go undetected. This addresses the type of attack that became notorious after the 2011 DigiNotar breach, which led to the creation of hundreds of fraudulent certificates.
A Phased Rollout Through 2027
Google is proceeding carefully. The current Phase 1 is a feasibility study: preliminary MTC support has been integrated into Chrome, and Cloudflare is generating the distributed ledger while enrolling approximately 1,000 TLS certificates into the new system for evaluation. Crucially, every MTC-enabled connection in this phase is backed by a traditional X.509 certificate as a safety net, meaning nothing breaks for end users if issues arise.
Phase 2, planned for Q1 2027, will invite existing Certificate Transparency log operators — those with at least one usable log in Chrome before February 1, 2026 — to help bootstrap a public MTC infrastructure. Google cites their experience running high-availability global security services as uniquely qualifying them for this role.
Phase 3, targeted for Q3 2027, introduces the Chrome Quantum-resistant Root Store (CQRS) — a new, dedicated trust store designed specifically for MTCs. The CQRS will operate in parallel with the existing Chrome Root Store, and Google has indicated it does not plan to add traditional X.509 certificates containing post-quantum cryptography to the current Chrome Root Store, making MTCs the primary path forward for quantum-safe HTTPS on the public web.
Industry Coordination Underway
Google is not working in isolation. The Internet Engineering Task Force (IETF) has established a dedicated working group, called PLANTS (PKI, Logs, and Tree Signatures), to develop MTC technology as an open, interoperable standard. The involvement of a formal standards body signals that the industry broadly views the quantum threat to web PKI as a concrete problem requiring coordinated action, not merely a theoretical future concern.
For the billions of users who rely on the padlock icon in their browser every day, the change should eventually be invisible. The goal of the entire initiative is precisely to maintain today’s seamless browsing experience while quietly upgrading the cryptographic foundations underneath — before quantum computers powerful enough to threaten them actually arrive.
Sources: Google Online Security Blog (February 28, 2026); Ars Technica; TechSpot; SecurityBrief
