3 ms·

Robust and efficient quantum-safe HTTPS

119 points by tptacek 9mo ago

utopiah 9mo ago
FWIW if you want to tinker on the topic I recommend OQS https://github.com/open-quantum-safe/ https://github.com/open-quantum-safe/ including Chromium, Apache, nginx, curl, etc. It's quite fun to play with.
- westurner 9mo ago
  What are appropriate default parameters? The mozilla SSL Config Generator doesn't yet support PQ; it has Old, Intermediate, and Modern: https://ssl-config.mozilla.org/ https://ssl-config.mozilla.org/ mozilla/ssl-config-generator: https://github.com/mozilla/ssl-config-generator https://github.com/mozilla/ssl-config-generator "Chrome switching to NIST-approved ML-KEM quantum encryption" (2024) https://news.ycombinator.com/item?id=42265927 https://news.ycombinator.com/item?id=42265927 "ML-KEM Mythbusting" (2025) https://news.ycombinator.com/item?id=46074381 https://news.ycombinator.com/item?id=46074381 re: AuthKEM
  - bwesterb 9mo ago
    Yeah, filed https://github.com/mozilla/ssl-config-generator/issues/342 https://github.com/mozilla/ssl-config-generator/issues/342
boutell 9mo ago
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.
- utopiah 9mo ago
  Discussed few weeks ago on https://community.letsencrypt.org/t/post-quantum-crypto-roadmap/245173 https://community.letsencrypt.org/t/post-quantum-crypto-road... specifically "The path we're more interested in is Merkle Tree Certificates, currently in design at the PLANTS working group at IETF. Chrome has indicated that they anticipate this to be their preferred approach to PQC. We're following that very closely, and are likely to deploy MTCs if it looks like that design is going to be supported widely." according to Matthew McPherrin, Let's Encrypt staff
  - westurner 9mo ago
    There are also Merkle ladders. What is the difference between a Merkle Tree Certificate and a Merkle Ladder? Is this correct?: Without Merkle Tree Certificates, the per keypress overhead for e.g. jupyter_server would be something like 3.3 KB due to the PQ signatures.
    - bwesterb 9mo ago
      Merkle Tree Certificates basically uses the same structure as Certificate Transparency today. Merkle Ladder uses a weird variation claimed to be useful to DNSSEC. I think it's rather just to seem novel ( https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-harvey-cfrg-mtl-mode https://datatracker.ietf.org/ipr/search/?submit=draft&id=dra... )
      - westurner 9mo ago
        I found buzzwords for this; Quantum-Resistant Decentralized PKI / DNS: Multilinear/Hash-based VCs and Sum-Check protocol for Stateless PKI (with Sparse Merkle Tree (SMT)) PKI-over-Log with Hyper-Trees, Decentralized PKI (DPKI), XMSS^MT, M-FORS and F-SPHINCS+ (stateless), "Spartan: Efficient and General-purpose zkSNARKs without Trusted Setup" (2020) https://link.springer.com/chapter/10.1007/978-3-030-56877-1_25 https://link.springer.com/chapter/10.1007/978-3-030-56877-1_... : - Spartan implements the Sum-Check protocol with Multilinear Polynomial Commitments, which is hash-based like XMSS and SPHINCS+ (unlike Verkle trees which are built on KZG which relies on the "Discrete Logarithm Problem" (which Shor’s broke)).
kro 9mo ago
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
- bwesterb 9mo ago
  Also just now Chrome published https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/ https://www.chromium.org/Home/chromium-security/post-quantum...
Veserv 9mo ago
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-clever-math-to-quantum-proof-https-certificates/ https://arstechnica.com/security/2026/02/google-is-using-cle...
- agwa 9mo ago
  At the beginning of a TCP connection, which is when the certificate chain is sent, you can't send more data than the initial congestion window without waiting for it to be acknowledged. 160KB is far beyond the initial congestion window, so on a high-latency connection the additional time would be higher than the numbers you calculated. Of course, if the web page is very bloated the user might not notice, but not all pages are bloated. The increased certificate size would also be painful for Certificate Transparency logs, which are required to store certificates and transmit them to anyone who asks. MTC doesn't require logs to store the subject public key.
  - Veserv 9mo ago
    That is exactly the type of poor design that I was saying should be rectified. You can already configure your initial congestion window, and if you are connecting to a system expecting the use of PQ encryption, you should set your initial congestion window to be large enough for the certificate; doing otherwise is height of incompetence and should be fixed. You could also use better protocols like QUIC which has a independently flow controlled crypto stream and you can avoid amplification attacks by pre-sending adequate amounts of data to stop amplification prevention from activating. And I fail to see how going from 4 KB of certificate chain to 160 KB of certificate chain poses a serious storage or transmission problem. You can fit literal millions into RAM on reasonable servers. You can fit literal billions into storage on reasonable servers. Sure, if you exactly right-sized your CT servers you might need to upgrade them, but the absolute amount of resources you need for this is miniscule.
Helloyello 9mo ago
[dead]

119 points by tptacek 9mo ago

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

westurner 9mo ago
What are appropriate default parameters? The mozilla SSL Config Generator doesn't yet support PQ; it has Old, Intermediate, and Modern: https://ssl-config.mozilla.org/ https://ssl-config.mozilla.org/ mozilla/ssl-config-generator: https://github.com/mozilla/ssl-config-generator https://github.com/mozilla/ssl-config-generator "Chrome switching to NIST-approved ML-KEM quantum encryption" (2024) https://news.ycombinator.com/item?id=42265927 https://news.ycombinator.com/item?id=42265927 "ML-KEM Mythbusting" (2025) https://news.ycombinator.com/item?id=46074381 https://news.ycombinator.com/item?id=46074381 re: AuthKEM
- bwesterb 9mo ago
  Yeah, filed https://github.com/mozilla/ssl-config-generator/issues/342 https://github.com/mozilla/ssl-config-generator/issues/342

boutell 9mo ago

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.

utopiah 9mo ago
Discussed few weeks ago on https://community.letsencrypt.org/t/post-quantum-crypto-roadmap/245173 https://community.letsencrypt.org/t/post-quantum-crypto-road... specifically "The path we're more interested in is Merkle Tree Certificates, currently in design at the PLANTS working group at IETF. Chrome has indicated that they anticipate this to be their preferred approach to PQC. We're following that very closely, and are likely to deploy MTCs if it looks like that design is going to be supported widely." according to Matthew McPherrin, Let's Encrypt staff
- westurner 9mo ago
  There are also Merkle ladders. What is the difference between a Merkle Tree Certificate and a Merkle Ladder? Is this correct?: Without Merkle Tree Certificates, the per keypress overhead for e.g. jupyter_server would be something like 3.3 KB due to the PQ signatures.
  - bwesterb 9mo ago
    Merkle Tree Certificates basically uses the same structure as Certificate Transparency today. Merkle Ladder uses a weird variation claimed to be useful to DNSSEC. I think it's rather just to seem novel ( https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-harvey-cfrg-mtl-mode https://datatracker.ietf.org/ipr/search/?submit=draft&id=dra... )
    - westurner 9mo ago
      I found buzzwords for this; Quantum-Resistant Decentralized PKI / DNS: Multilinear/Hash-based VCs and Sum-Check protocol for Stateless PKI (with Sparse Merkle Tree (SMT)) PKI-over-Log with Hyper-Trees, Decentralized PKI (DPKI), XMSS^MT, M-FORS and F-SPHINCS+ (stateless), "Spartan: Efficient and General-purpose zkSNARKs without Trusted Setup" (2020) https://link.springer.com/chapter/10.1007/978-3-030-56877-1_25 https://link.springer.com/chapter/10.1007/978-3-030-56877-1_... : - Spartan implements the Sum-Check protocol with Multilinear Polynomial Commitments, which is hash-based like XMSS and SPHINCS+ (unlike Verkle trees which are built on KZG which relies on the "Discrete Logarithm Problem" (which Shor’s broke)).

kro 9mo ago

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

bwesterb 9mo ago
Also just now Chrome published https://www.chromium.org/Home/chromium-security/post-quantum-auth-roadmap/ https://www.chromium.org/Home/chromium-security/post-quantum...

Veserv 9mo ago

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-clever-math-to-quantum-proof-https-certificates/ https://arstechnica.com/security/2026/02/google-is-using-cle...

agwa 9mo ago
At the beginning of a TCP connection, which is when the certificate chain is sent, you can't send more data than the initial congestion window without waiting for it to be acknowledged. 160KB is far beyond the initial congestion window, so on a high-latency connection the additional time would be higher than the numbers you calculated. Of course, if the web page is very bloated the user might not notice, but not all pages are bloated. The increased certificate size would also be painful for Certificate Transparency logs, which are required to store certificates and transmit them to anyone who asks. MTC doesn't require logs to store the subject public key.
- Veserv 9mo ago
  That is exactly the type of poor design that I was saying should be rectified. You can already configure your initial congestion window, and if you are connecting to a system expecting the use of PQ encryption, you should set your initial congestion window to be large enough for the certificate; doing otherwise is height of incompetence and should be fixed. You could also use better protocols like QUIC which has a independently flow controlled crypto stream and you can avoid amplification attacks by pre-sending adequate amounts of data to stop amplification prevention from activating. And I fail to see how going from 4 KB of certificate chain to 160 KB of certificate chain poses a serious storage or transmission problem. You can fit literal millions into RAM on reasonable servers. You can fit literal billions into storage on reasonable servers. Sure, if you exactly right-sized your CT servers you might need to upgrade them, but the absolute amount of resources you need for this is miniscule.

Helloyello 9mo ago

[dead]