Google has devised a means for securing HTTPS certificates against quantum computing attacks without massive performance hits stemming from the considerably longer size of data required to be included.

Is anyone following this work?

https://security.googleblog.com/2026/02/cultivating-robust-and-efficient.html

Cultivating a robust and efficient quantum-safe HTTPS

Posted by Chrome Secure Web and Networking Team Today we're announcing a new program in Chrome to make HTTPS certificates secure against ...

Google Online Security Blog
@dangoodin this problem has been solved for a while using symmetric encryption after a QR assymetric handshake for a while now, no?

@andrei_chiffa

Great question . . . and one I don't know the answer to.

@andrei_chiffa @dangoodin The QR asymmetric handshake protects against passive attackers decrypting sniffed traffic, but not against active attackers presenting a forged certificate in a man-in-the-middle attack. Merkle Tree Certificates protect against the latter threat.
@andrei_chiffa @dangoodin the issue is the size of the handshake itself. You have to run the entire handshake before you can transmit data. With PQC, what used to be a 32 to 256 byte public key or signature now each becomes 1 to 3.5 KB in size. This is acceptable for the key agreement parts, since we really only need one artifact per party there, but becomes way too expensive when talking about the certificate, i.e. a chain of public keys signed by keys further up.
Merkle Tree Certificates are a proposal that significantly compresses this certificate chain, at the cost of a more complicated trust management story.
@sophieschmieg @andrei_chiffa @dangoodin Dan: The scale of the problem is spelled out pretty clearly in this presentation from the last IETF: https://youtu.be/wBR_MIFc08I?si=85y_tlGfEdREkFRd&t=1027
IETF 124: PKI, Logs, And Tree Signatures (PLANTS) 2025-11-04 22:00

YouTube
@sophieschmieg @andrei_chiffa @dangoodin I’m a bit confused by this. The client is still going to need the public keys, right? So is this just replacing the signatures with a Merkle proof? Have you done a blockchain??!
@[email protected] it's ironic because CT logs were introduced because we didn't trust CAs. Now we should trust the CA, the cosigners, and the CT logs.

@[email protected] @[email protected]
@i @andrei_chiffa @dangoodin no, the CT logs still function as CT logs in mtc. They do away with the imperfection of CT logs requiring signatures instead of being published immediately, and they use the fact that the CT log itself can function as a certificate, but the trust model isn't relaxed, it's just more complicated.
@[email protected] what I'm trying to say is: the number of moving parts, that I need to trust or verify is increasing. And that is not really comforting.

Am I missing something here?

@[email protected] @dangoodin
@i @andrei_chiffa @dangoodin you can always request and verify the fallback certificate, which is just a normal cert chain backed by ML-DSA. MTC is an optional optimization mechanism for the browser, that also fixes an issue CT had while we're at it.
@[email protected] got it! Thanks for the clarification.
Chrome shares their plans for post-quantum certificates. https://lnkd.in/eBM2qeTs They're not going to accept the large drop-in post-quantum signatures, but instead go the extra mile to keep the… | Bas Westerbaan

Chrome shares their plans for post-quantum certificates. https://lnkd.in/eBM2qeTs They're not going to accept the large drop-in post-quantum signatures, but instead go the extra mile to keep the Internet fast and secure using Merkle Tree Certificates. This is happening now: Chrome and Cloudflare are running a feasibility experiment as we speak. Chrome plans to ship the first proper Merkle Tree CA in their rootstore in 2027.

@dangoodin A colleague came up with a similar algorithm for one of our problems so I'm familiar with the concept. In our case it was making sure a firehose of data was correct once received. It wasn't productionised due to the pitiful amounts of money related to the product.
@dangoodin They are probably the same assholes that decided that TLS certificates will expire every 47 days.
@dangoodin Yeah, but I'm a weirdo who goes to IETF meetings and cares about this stuff. You can watch the PLANTS meeting from Novermber's IETF meeting here: https://www.youtube.com/watch?v=wBR_MIFc08I
IETF 124: PKI, Logs, And Tree Signatures (PLANTS) 2025-11-04 22:00

YouTube
@dangoodin Yes, closely. There's a lot of momentum and Mozilla and Apple are interested as well.
@dangoodin yes. 😏
@sophieschmieg @dangoodin @filippo 82 pages of RFC…hmmm…must be secure then!😌
@icing @sophieschmieg @dangoodin it's mostly very well-tested stuff from the tlog ecosystem. The Go sumdb has had zero security incidents since 2019. The same is not true of our crypto/x509. But please do report any issues!
@filippo @icing @sophieschmieg @dangoodin it's kinda straightforward but it's not trivial

@dangoodin

Who cares about the certs if you are behind a defacto MITM like Cloudflare?

@dangoodin

This is Security Theatre.

@[email protected] Firefox never really forced CT logged, but with this proposal it seems to me that you now have to trust that a CA can properly maintain a log and also trust the cosigners at the same time.

@[email protected]
@dangoodin My question is, how close are we to hardware that can do quantum attacks on encryption?
@tknarr @dangoodin don't forget how slow certain technology adoption rates are.
You only need one person to have the capabilities to use quantum computer for this meanwhile every website needs to update which will take a while

@thibaultmol @dangoodin Yes. It won't be just one person though, just as it wasn't just one person who got the first computer made using ICs. It'll be a steady progression across such a large set of organizations that there'll be no way not to broadcast the state of the hardware. We'll know well before the first unit that can do the job in a reasonable amount of time is produced.

The question needs asked and answered: what's the earliest we can reasonably expect the first one...

@thibaultmol @dangoodin ... that can do the job at all to arrive? Without a timeframe, planning a response is a bad idea. You need a response in place before that deadline, but if you rush things you end up with sub-par results that won't hold up against the inevitable advances. So we really need to know if we're on a 5 year deadline vs. 10, 25, 50.

Personally I think it's closer to 50 than 10.

This is the NSA timeline for PQC. Other countries (EU, UK, etc.) have similar timelines between 2030 and 2035.

I, however, do not think that we will have any Cryptographically Relevant Quantum Computers (CRQC) in the next decades.

CC: @[email protected] @[email protected]
@dangoodin seeing the cryptography nerds do their thing, and all I see is word salad, dreading the day I have to learn anything about certificates and cryptography beyond a Cæsar cypher in school.
@dangoodin Exciting, but also seems heavily focused on the needs of hyperscalers. Will roll out in Chrome and Cloudflare only at first, others get left behind. Requires a public Merkle tree, no thought seems to have been given to private CAs. And at the same time, Chrome is sabotaging the existing ML-DSA certificates (that already work today, albeit slow), by not implementing them.
@dangoodin @briankrebs no, quantum computing is nothing.