The web’s quantum-security upgrade has a size problem

A website-security upgrade is not finished when a stronger algorithm exists. It also has to travel across ordinary networks and work with the software people already use. New funding for Let’s Encrypt, the nonprofit-backed service that issues free website certificates, is aimed at that practical part of the post-quantum transition.

On November 5, Let’s Encrypt and the Sovereign Tech Agency announced support worth more than €1 million for work on a Merkle Tree Certificate Authority through the end of 2027. It is funding for infrastructure development, not an announcement that every website now uses quantum-resistant certificates.

Two jobs that are easy to confuse

A secure connection has to protect the traffic and help establish who is on the other end. Those are related, but distinct, cryptographic jobs. The certificate work here concerns authentication: giving a browser grounds to trust a server’s identity. It should not be described as though a new certificate design alone completes every part of the post-quantum transition.

The concern is a future quantum computer powerful enough to attack today’s authentication signatures, not a claim that present machines can do so. A certificate binds a domain to a cryptographic key; it does not certify that the business behind a website is honest.

Let’s Encrypt’s earlier technical account explains the deployment problem. Post-quantum signatures can be larger than the signatures commonly used in today’s certificate infrastructure. Simply replacing each item in a familiar chain can increase the amount of authentication data sent during a connection.

The question is therefore not merely which signature to choose. It is whether the surrounding system can avoid repeating work that does not need to be repeated.

Prove membership in a batch

The proposed Merkle Tree Certificate approach groups certificates into a cryptographic structure. Instead of treating every certificate as an isolated signing job that has to carry the same style of proof chain, a client can use a compact proof that a certificate belongs to an authenticated batch. Browser support and fallback behavior remain part of the engineering task.

A small, simplified example helps explain the appeal. Imagine a balanced tree containing eight records. A membership proof can identify a path using three sibling hashes, or digital fingerprints. With 1,024 records in the same idealized structure, the path uses ten. Increasing the number of records by a factor of 128 increases this path length from three to ten, not to 384.

That is an illustration of a binary tree, not a prediction of the complete protocol’s wire size. Real messages also need the relevant keys, signatures, identifiers and encodings. Clients need a trusted starting point and current information about the signed tree. Omitting those parts would turn a useful analogy into a false performance claim.

The basic idea is still understandable: organize the evidence so that a connection does not have to carry an unnecessarily bulky demonstration from scratch.

Standards, software and deployment must meet

The current IETF specification, revision 08 dated November 2, is an Internet-Draft: a work in progress, not a final internet standard. There are several separate milestones between a funded project and a widely deployed security feature. Implementations need to agree on the protocol. Browsers and servers need compatible support. Operators need workable issuance and renewal processes. The fallback path needs to function when a client does not have the expected information.

A scheme that looks compact in a diagram can still encounter compatibility problems. Equally, a design should not be dismissed simply because it changes a familiar certificate format. The useful evidence is how the whole system behaves, including the cases that are less convenient than the demonstration.

That is why dates in this story should be treated as development targets. The funding announcement supports work toward production readiness; it does not eliminate the dependencies on the wider browser and standards ecosystem.

What readers should watch next

For Let’s Encrypt, the next milestones are a publicly accessible staging service and then production readiness, with browser requirements still a dependency. Those are more specific tests of progress than another broad promise about quantum-safe security.

Our earlier account of the web’s changing locks explains the broader transition. This new funding addresses one specific part: making the proof of identity practical to transmit.

For now, the story is a useful reminder that post-quantum security is an infrastructure problem as well as a mathematical one. Stronger authentication has to remain deployable. The size of the proof can matter almost as much as the strength of the signature.