Robust and efficient quantum-safe HTTPS

FWIW if you want to tinker on the topic I recommend OQS https://github.com/open-quantum-safe/ including Chromium, Apache, nginx, curl, etc. It's quite fun to play with.

The title is vague, my first thought was "We already have MLKEM". Which is enough against passive attackers.

The article apparently is about the CA/certs for authenticating the server, a part of HTTPS

The pivot to MTC is a big change in the infrastructure of https. I wish other browsers were at least mentioned in this blog post. I'm curious about the future of letsencrypt as well.

[dead]

While I appreciate more efficient and compact representations, I fail to see why this is particularly necessary. This article [1] on the same topic indicates a naive PQ chain is only ~40x the size of a current 4 KB chain. That means it is just ~160 KB.

If you have the legal minimum to be considered broadband in the US, you need ~100 Mbps, so that would add ~12 ms.

If you can stream one 4K video, you need ~20-40 Mbps, so that would add ~30-60 ms.

If you can stream one 1080p video you need to ~3-6 Mbps, so that would add ~200-400 ms.

Even on just a 1 Mbps connection, just barely enough to stream a single 480p video that would only add ~1 second.

And I doubt the weight of most of pages is lower than 160 KB. Many of them are probably dramatically higher, so the total effect of a extra 160 KB is just a few percent.

If there is a problem, it seems like it would be with poorly designed protocols and infrastructure which should be fixed as well instead of papering them over.

[1] https://arstechnica.com/security/2026/02/google-is-using-cle...