31 March 2026
Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić.
In the past several years, the world has been busy with the migration to post-quantum cryptography, but you couldn’t hear much of Google's plans when it comes to Web PKI. However, work has been in progress for several years, going back to at least early 2023. In late 2025, joining with other interested parties, Google migrated its work to an IETF working group called PLANTS. Work is now ongoing to refine the design and validate it in collaboration with Cloudflare. Recently, Google published a blog post to officially announce this work and provide further details about its future steps. In short, the core design is baked, and the remainder of 2026 will be spent on validating the core technology. In 2027, Google will bootstrap the next-generation Web PKI.
It’s fortunate that cryptographically relevant quantum computers don’t pose a threat against authentication on the web until they actually materialize. The effort so far has been on protecting the key exchange of the TLS handshake, which is susceptible to “store now, decrypt later” attacks. Chrome and other major browsers mitigated this immediate threat by deploying X25519MLKEM768. Now the rest of the world needs to catch up by adding support for this post-quantum safe key exchange on the server side.
Because there is time, Google is taking the opportunity to make some substantial changes to how Web PKI operates. Crucially, Google is further refining the concept of Certificate Transparency (CT) and, in fact, merging it with certificate issuance so that they are inseparable. The new design is reworking trust and introducing massive complexity into the ecosystem, but, if it’s successful, the transition to post-quantum cryptography will not introduce a performance regression for Web PKI.
There are two driving forces behind the redesign effort. First, there is a problem with the massive increase in public key and signature sizes of the new post-quantum cryptographic algorithms. At present, our most efficient algorithm (EC) takes only sixty-four bytes for a public key or signature, compared to 1,312 bytes for a ML-DSA-44 public key and 2,420 bytes for a signature. A typical TLS handshake may include two public keys and five signatures. Upgrading just the algorithms would increase the size of the signature ten times. This, for Google, is an unacceptable performance regression, at least when it comes to public web traffic.
The other problem is with CT, which has been deeply embedded in Web PKI since 2018. CT has been enormously successful in terms of providing ecosystem visibility, but running it hasn’t been smooth. In fact, it remains fragile—and yet it’s at the center of certificate issuance. If CT breaks, all issuance breaks. The increasing PQC signature sizes would impact CT a great deal also, because CT log entries contain one public key and signature. A tenfold increase in the size of the logs would break the current arrangement. To make this situation worse, the ecosystem is transitioning to enforced forty-seven-day certificates in 2029, which will lead to a substantially increased number of certificates, further increasing the size of the data.
Google’s solution is Merkle Tree Certificates (MTCs), an evolution of X.509 certificates that change how trust is implemented. The core idea is to switch to so-called landmark certificates (in MTC terminology) that don’t include any signatures at all. At the moment, a fully formed X.509 certificate contains a public key, one signature from a CA, and two signatures from CT. In the new design, the public key remains in the certificate, but the rest can be replaced with an inclusion proof, leading to a massive decrease in certificate size when post-quantum cryptography is taken into account. We can’t magically do away with any signatures, but they can be moved elsewhere so that they’re not used or needed most of the time.
The next-generation CT will benefit from several key design decisions: (1) CT log entries will not contain certificate public keys or CA signatures; (2) precertificates are being removed, reducing the amount of data needed for the logging; and (3) ecosystem-wide duplication will be eliminated by having CT logs contain only certificates issued by a single CA and removing public submissions (which don’t add value any more but do increase data requirements).
Google has decided to pursue MTCs as a mitigation for the increase in the size of post-quantum cryptography and the next step in the evolution of CT. The company is on the record as saying that it won’t support PQC-enabled X.509 certificates for public properties, unless there is no other option. However, Google has also said that private PKIs will not be affected. That makes sense, but it’s not clear who would operate the complex infrastructure for private issuance.
At the same time, the increased public key and signature size of post-quantum cryptography will not affect private PKIs as much. As such, private certificates don’t use CT, meaning that they don’t need the two extra signatures that are embedded in public certificates. That also means that there isn’t any CT infrastructure to worry about. Moreover, a new standard called Trust Anchor Identifiers (developed in parallel with MTC) will make it possible to remove intermediate certificates from the TLS handshake, reducing its size by one public key and one signature. When these are added up, private PKI handshakes will need to carry only one public key (in the certificate) and two signatures (one CA signature on the certificate and one signature for the TLS handshake itself). This will be bigger than it is now, but acceptable for many use cases.
The new design will mitigate the changes required by post-quantum cryptography—but at what cost? Rearchitecting issuance and building of an entirely new ecosystem to issue MTCs is a massive effort. Google is doing most of the work, with CAs to follow. Once MTCs are implemented, we will have two issuance platforms, the old and the new. Web PKI will further diverge from all other PKIs.
The TLS handshake also will need to change, which means that, eventually, all server platforms will need to update. It’s not going to be a straightforward update, either. The problem with landmark certificates is that they require out-of-band communication between relying parties (e.g., browsers) and future CT logs. It may take several days until the necessary information is propagated. In the meantime, standalone certificates, which are very similar to existing X.509 certificates, have to be used. To make this work, every server will need to support multiple valid certificates of different types (standard X.509, standalone MTC, landmark MTC) and support complex TLS handshake negotiation to ensure each user agent is offered a certificate they will accept. Troubleshooting TLS and PKI has never been easy, but it’s about to get much more complicated.
This subscription is just for the newsletter; we won't send you anything else.
A couple of days ago, Google announced that it was accelerating its deadline for migrating to post-quantum cryptography, citing advances in quantum computing hardware, as well as the growing threat of store now, decrypt later attacks. Google is now planning to complete this work by 2029. Today, as we were about to publish this newsletter, the clues behind the decision came to light, and there are two of them.
First, Google Research released a strongly worded paper describing a new and significantly better algorithm that can be used to break elliptic curve cryptography. They’re claiming “nearly a 20 fold reduction over prior estimates” for attacks against secp256k1. Additionally, they say that it might be possible to achieve the break in only minutes. Google has decided not to release the details of the algorithm, instead publishing a zero-knowledge proof that they have it. As a reminder, virtually all cryptocurrencies run on top of elliptic curve cryptography.
Shor's algorithm breaks most classic cryptography—RSA, ECC, and Diffie-Hellman—but ECC falls first because its smaller key sizes require fewer quantum resources than RSA, despite harder per-bit arithmetic. Attacks against ECC have become more successful recently, and that was before we learned about the most recent research paper.
The second clue for Google’s decision might be the other research paper just published, which claims that breaking RSA requires only 10,000 reconfigurable atomic qubits, a much lower number than previously estimated. It seems that the race is on: which is breaking first, ECC or RSA?
Encrypted Client Hello (ECH) has been standardized as RFC 9849. This addition to TLS 1.3 makes it possible to encrypt the very first message exchanged with a server, which in turn protects sensitive information in the TLS handshake, such as the exact identity of the server (also known as Server Name Indication, or SNI). The companion document, RFC 9848, creates a mechanism to discover ECH configuration and encryption keys via SVCB/HTTPS resource records. For a light introduction, head to our July 2025 newsletter in which we provided more information. ECH has the potential to lead to much better privacy online, but it may also impact legitimate security operations.
id-kp-documentSigning) specifically for certificates used to digitally sign human-readable documents, separating this use case from the previously misappropriated id-kp-emailProtection and id-kp-codeSigning identifiers to reduce cross-protocol attack risks.We may sometimes use Anthropic’s Claude to help us create short news summaries.
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.