Keeping the Internet fast and secure: introducing Merkle Tree Certificates
23 comments
·October 28, 2025mcpherrinm
Next week at IETF 124, there's a Birds-of-a-Feather session that will kick off the standardization process here.
I think Merkle Tree Certificates a promising option. I'll be participating in the standardization efforts.
Chrome has signalled in multiple venues that they anticipate this to be their preferred (or only) option for post-quantum certificates, so it seems fairly likely we will deploy this in the coming years
I work for Let's Encrypt, but this is not an official statement or promise to implement anything yet. For that you can subscribe to our newsletter :)
cryptonector
I think MTC is best described as a new signature algorithm for signing certificates where the value is a Merkle tree inclusion proof. This is quite clever. I like it.
tempay
> All the information a client needs to validate a Merkle Tree Certificate can be disseminated out-of-band.
The post didn't discuss it but naively this feels like it becomes a privacy issue?
megous
It would be ridiculous for cloudflare to discuss privacy issues. ;-)
itopaloglu83
Here’s what I’m not following in general about the Post Quantum encryption studies.
Don’t we already just use the certificates to just negotiate the final encryption keys? Wouldn’t a quantum computer still crack the agreed upon keys without the exchange details?
mcpherrinm
Yes, the rest of the cryptography needs to be PQ-secure as well.
But that's largely already true:
The key exchange is now typically done with X25519MLKEM768, a hybrid of the traditional x25519 and ML-KEM-768, which is post-quantum secure.
The exchanged keys typically AES-128 or AES-256 or ChaCha20. These are likely to be much more secure against quantum computers as well (while they may be weakened, it is likely we have plenty of security margin left).
Changing the key exchange or transport encryption protocols however is much, much easier, as it's negotiated and we can add new options right away.
Certificates are the trickiest piece to change and upgrade, so even though Q-day is likely years away still, we need to start working on this now.
Upgrading the key exchange has already happened because of the risk of capture-now, decrypt-later attacks, where you sniff traffic now and break it in the future.
throwaway89201
> Don’t we already just use the certificates to just negotiate the final encryption keys?
No, since forward secret key agreement the certificate private key isn't involved at all in the secrecy of the session keys; the private key only proves the authenticity of the connection / the session keys.
mtoner23
No the agreed upon keys are symmetric encryption keys with like an AES cipher and we don't have any reason to believe the current encryption there is easier to calculate with a quantum computer
null
NoahZuniga
While quantum computing weakens AES encyption, AES 256 bit can't be cracked by quantum computers.
MangoToupe
Not practically, anyway, and even with absurd advances we can just grow the key sizes.
jokoon
Are we already talking about attackers having access to quantum computers?
I could see government agencies with a big budget having access to it, but I don't see those computers becoming mainstream
Although I could see China having access to it, which is problem.
mcpherrinm
The migration here is going to be long.
Chrome and Cloudflare are doing a MTC experiment this year. We'll work on standardizing over the next year. Let's Encrypt may start adding support the year after that. Downstream software might start deploying support MTCs the year after that. People using LTS Linux distros might not upgrade software for another 5 years after that. People run out-of-date client devices for another 5 years too.
So even in that timeline, which is about as fast as any internet-scale migration goes, it may be 10-15 years from today for MTC support to be fully widespread.
mtoner23
The fear is attackers are recording conversations today in the hopes that they can crack the encryption when we do have quantum computers in a few years
mcpherrinm
Capture-now Decrypt-later isn't really relevant to certificates, who mostly exist to defend against active MITM. The key exchange algorithms need to be PQ-secure for CN-DL, but that has already happened if you have an up-to-date client and server.
HexDecOctBin
> Although I could see China having access to it, which is problem.
I can see USA having access to it, which is also a problem. Or any other government.
tptacek
No. Nobody serious that I know of thinks Q-day has occurred or will occur in 2025. The more typical question is whether we're 10, 50, or 100 years away from it.
rynn
Seems like you answered your own question
megous
Ah cloudflare. But who will protect us against cloudflare???
It's a privacy violating proxy after all.
thhoooowww0101
What's so special about cloudflare? Everyone from AWS to Akamai offers the same "reverse proxy" service.
There's a section missing on the inclusion proof and what exactly the clients will be getting.
If I understand this correctly each CA publishes a signed list of landmarks at some cadence (weekly)
For the certs you get the landmark (a 256-bit hash) and the hashes along the merkle path to the leaf cert's hash. For a landmark that contains N certs, you need to include log2(N) * hash_len bytes and perform log2(N) hash computations.
For a MTC signature that uses a 256bit hash and N=1 million that's about 20*32=620bytes.
Is this the gist of it?