Dan GoodinFeb 27

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
Show threadAndrei KucharavyFeb 27
@dangoodin this problem has been solved for a while using symmetric encryption after a QR assymetric handshake for a while now, no?
Show threadSophie Schmieg
@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.
Feb 27 at 9:57pmWeb
Show threadBob RobertsFeb 27
@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
Show threadNeil MaddenFeb 28
@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??!
Show threadپویان Pouyan Feb 28
@[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]
Show threadSophie SchmiegFeb 28
@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.
Show threadپویان Pouyan Feb 28
@[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
Show threadSophie SchmiegFeb 28
@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.
Show threadپویان Pouyan Feb 28
@[email protected] got it! Thanks for the clarification.