Pith. sign in

REVIEW 4 major objections 5 minor 79 references

Mind the Gap: Policy vs Reality in Post-Quantum TLS Deployment

T0 review · 4 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash

Pith's one-line read This paper measures post-quantum TLS across the public Internet and finds that despite divergent policy guidance, deployment has converged on a single hybrid construction, is driven almost entirely by managed CDN platforms, and adds no mean

desk verdict A solid, useful measurement paper on PQ-TLS deployment; the infrastructure-attribution heuristic is the one thing I'd want validated before leaning on the headline numbers. read the letter →

arxiv 2607.29005 v1 pith:5VXYWEJG submitted 2026-07-31 cs.NI cs.CR

classification cs.NIcs.CR
keywords post-quantumcryptographyTLSPQ-TLSdeploymentInternetmeasurementhybridkeyexchangeML-KEMX25519MLKEM768policyalignment
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper establishes the first longitudinal, vendor-agnostic picture of how post-quantum cryptography is actually being deployed in TLS after NIST standardization, based on more than two billion handshakes to a million domains from eleven global vantage points. It finds that, despite widely varying national policy recommendations, operational PQ-TLS has converged on a single hybrid key exchange, X25519MLKEM768, which nearly half (49.22%) of a stable panel of 684,494 domains defaults to by March 2026. The paper shows this adoption is overwhelmingly driven by a few managed infrastructure providers, with Cloudflare and Fastly together accounting for nearly 70%, while owner-managed and government domains remain mostly classical. National timelines and sectoral priorities show little correspondence with observed deployment. It also finds that PQ-TLS introduces no meaningful handshake latency increase in Internet settings, although it is often deployed alongside legacy TLS configurations. The sympathetic reader cares because these results suggest that the post-quantum transition is being shaped more by platform defaults than by policy, and that aggregate adoption statistics can overstate security modernization.

What carries the argument

The central object is the TLS 1.3 handshake negotiation itself, observed through a custom scanning client that advertises NIST-standardized PQC algorithms; the paper isolates the hybrid key exchange group X25519MLKEM768 as the single construction that dominates real-world defaults. Two mechanisms carry the argument: a differential measurement design that performs matched PQ and classical baseline handshake pairs spaced four hours apart, allowing per-domain latency deltas to be attributed to the PQ component; and a TLS management attribution heuristic that classifies each domain as 'potentially infrastructure provider managed', 'potentially owner managed', or 'unknown' by layering IP-range ma

What would settle it

A ground-truth audit of a random sample of domains the heuristic labels 'potentially infrastructure provider managed'—for example, asking the operators of those domains or consulting platform configuration documentation—that found substantial misclassification would directly overturn the central 93.92% infrastructure-driven adoption figure.

Watch

Extended reading notes

Core claim

The paper presents the first longitudinal, vendor-agnostic measurement study of publicly deployed post-quantum TLS after NIST standardization. By actively probing over one million domains with a custom TLS 1.3 client from 11 globally distributed vantage points in three rounds (July 2025, November 2025, March 2026), it observes that operational PQ-TLS has effectively standardized on a single hybrid construction, X25519MLKEM768: every domain that negotiates PQ key exchange by default uses this group, and it rises from 31.26% of the stable panel to 49.22% over the study period. The authors find that 93.92% of PQ-TLS deployments come from infrastructure-provider-managed configurations, with Clou

Load-bearing premise

The claim that nearly all observable PQ-TLS adoption is infrastructure-driven rests on a heuristic that guesses, from IP ranges, DNS records, HTTP metadata, and AS ownership, whether a domain's TLS configuration is managed by its hosting platform or by the domain owner—a guess applied to 91% of the stable panel without any reported ground-truth validation or error rates.

Editorial extensions

If this is right

  • If current patterns hold, the post-quantum transition on the public web will be defined by the configuration choices of a handful of CDN platforms, not by national mandates or sectoral priorities.
  • The absence of a measurable latency penalty suggests that performance concerns should not delay PQ-TLS rollout; the only consistent operational cost is a ~1.1 KB increase in handshake message size per direction.
  • Because PQ-TLS is layered onto existing configurations, aggregate adoption numbers can overstate security progress; many PQ-enabled domains still support legacy TLS versions and deprecated ciphers.
  • Owner-managed and government domains lag well behind infrastructure-managed ones, implying that near-term policy deadlines (2030-2031) are unlikely to be met without targeted deployment support.
  • Alternative hybrid constructions (e.g., secp256r1MLKEM768, secp384r1MLKEM1024) appear only as non-default capabilities, indicating that the ecosystem is effectively dependent on a single hybrid construction.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A natural testable extension: if X25519MLKEM768 must be replaced (due to a security break or policy mandate), the infrastructure-mediated model predicts the fix would propagate quickly across most domains, while the long tail of owner-managed domains would remain stuck on whatever default their software ships with.
  • The paper's central 'infrastructure-mediated transition' narrative is only as strong as its attribution heuristic; a public validation study reporting error rates and inter-rater agreement for that classifier would be the most direct next step.
  • The speed of PQ-TLS adoption (47% in about 15 months) mirrors the TLS 1.3 rollout but is even faster due to the same platform-driven dynamics; if that analogy holds, PQ-TLS may plateau short of universal coverage because of long-tail inertia, leaving a persistent quantum-recording risk.
  • Since all latency measurements come from well-provisioned cloud vantage points, the 'no meaningful latency increase' claim may not generalize to constrained residential or mobile last-mile networks; replicated measurements from those environments would test that boundary.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper presents the first longitudinal, vendor-agnostic measurement study of post-quantum TLS (PQ-TLS) on the public HTTPS ecosystem after NIST standardization. The authors scan roughly one million domains from 11 geographically distributed cloud vantage points in three rounds (July 2025, November 2025, March 2026), building a stable panel of 684,494 domains. They report that default PQ-TLS negotiation converges on the single hybrid construction X25519MLKEM768, reaching 49.22% of the stable panel by March 2026; that 93.92% of PQ-TLS defaults are attributed to infrastructure-provider-managed TLS, with Cloudflare and Fastly together accounting for about 70%; that national transition timelines and sectoral priorities show limited correspondence with observed deployment; that hybrid PQ key exchange introduces no measurable latency increase in their measurements; and that PQ-TLS is frequently deployed alongside legacy TLS features. The paper also surveys PQC transition policies in eight jurisdictions and compares findings across DomCop, Tranco, and CrUX domain lists.

Significance. If the measurement and attribution concerns are adequately addressed, this would be a valuable and timely empirical contribution. The scale (2 billion handshakes, 1M domains, 11 vantage points, three rounds) and the paired differential-latency design are strengths. The paper's central observations — de facto convergence on X25519MLKEM768, infrastructure-mediated deployment, and negligible observed latency overhead — are policy-relevant and would be a useful benchmark for PQC transition planning. The robustness check across multiple top-domain lists (Appendix C) and the detailed protocol-security labeling criteria (Appendix E) support reproducibility. However, the headline 'infrastructure-driven transition' claim rests on an unvalidated attribution heuristic, and the stable panel excludes nearly one third of scanned domains; both issues must be addressed before the main findings can be considered established.

major comments (4)
  1. [§4.4, §5.2] The TLS-management attribution heuristic is load-bearing for RQ2, RQ3, and RQ5. It labels domains as 'potentially infrastructure provider managed' not only on direct IP/CNAME/PTR/AS matches but also on 'characteristics of shared hosting such as high IP fanout and known infrastructure-linked metadata.' The paper reports no ground-truth validation, precision/recall, or inter-rater agreement. A domain on shared hosting can have TLS configured by the domain owner through a control panel, so this extension may misclassify owner-managed deployments as infrastructure-managed. Since misclassification is plausibly correlated with PQ status, the 93.92% figure in §5.2 may materially overstate the infrastructure-mediation claim. Please provide a sensitivity analysis (e.g., reclassify shared-hosting/unknown labels to owner-managed and show how RQ2, Fig. 1, Fig. 3, and RQ5 results change) and validate
  2. [§5, Table 2] The stable panel is 684,494 of 1,000,000 domains (68.44%); the remaining 315,506 domains are excluded because they fail TLS 1.3 handshakes from at least one vantage point or round. PQ-TLS is observable only in TLS 1.3-capable endpoints, so the panel is likely biased toward modern infrastructure and against owner-managed and government domains, which the paper concludes are lagging. The statement that 'nearly half of the stable panel defaults to PQ-TLS' is conditional on this panel, not representative of the Top 1M as a whole. Please report adoption over all March 2026 successful scans (Table 4, n = 714,067) alongside the stable-panel figures, and provide a bounds analysis for excluded domains (e.g., using TLS 1.2 reachability and provider attribution to estimate an upper bound on PQ-TLS adoption across the full list).
  3. [Appendix C, Table 5 vs Table 2] Table 5 reports DomCop X25519MLKEM768 default of 49.74% for March 2026, while Table 2 gives 49.22% for the stable panel in the same month. The difference (about 0.52 percentage points, or roughly 18,000 domains) is not explained. If Table 5 uses all successful scans while Table 2 uses the stable panel, this should be stated explicitly and the two denominators reconciled. Since the abstract and conclusion rely on 'nearly half' of domains adopting PQ-TLS, the reader needs a single, clearly defined denominator for the headline adoption rate.
  4. [§5.3.4, Fig. 3] The claim that policy timelines show 'no clear evidence' of correspondence with deployment is based on mean adoption rates (32.4% vs 45.7%) and within-Cloudflare comparisons, but no confidence intervals, hypothesis tests, or provider-composition controls are reported. The apparent reversal could be driven by differences in CDN market share across ccTLD samples or by other confounders. Please provide a small regression or stratified table with confidence intervals; if the sample size is insufficient for inference, state that limitation explicitly. This is needed to support the strong RQ3 conclusion that infrastructure composition, rather than policy, explains cross-country differences.
minor comments (5)
  1. [Fig. 3] Typo: 'E-Commerece' should be 'E-Commerce'.
  2. [§5.4.1, Fig. 4] The caption reports ΔT p90 = 14 ms and 'over 90% of domains experience a latency difference of at most 14 ms,' while the text reports absolute handshake-time 90th-percentile difference of 5 ms. Please use consistent terminology (delta vs absolute) and clarify which quantity each statement refers to.
  3. [Table 1] The legend symbols (filled/hollow circles, squares, triangles) appear to be missing or mis-rendered in the table. Please ensure the notation is visible in the final version.
  4. [References] References [66] and [67] appear to be the same CoNEXT 2023 paper with the same author list; duplicate entries should be merged.
  5. [§5.5.1] 'compression mechanisms, which corresponds to a higher prevalence...' is grammatically awkward. Also, the phrase 'potentially infrastructure provider managed' in §4.4 is later used as the categorical 'infrastructure provider managed' in §5.2; please maintain the probabilistic qualifier throughout the results discussion.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: findings are observational measurements; the only self-citation is peripheral.

full rationale

This is an empirical measurement study, not a derivation. The central claims—(RQ1) convergence on X25519MLKEM768, (RQ2) infrastructure-driven adoption, (RQ4) negligible latency impact, and (RQ5) security co-evolution—are read directly from TLS handshake measurements. There are no fitted parameters, no equations that transform inputs into predictions, and no step in which the conclusion is assumed by definition. The TLS-management attribution heuristic in §4.4 is a classification rule applied to the measured domains; it is not a parameter fitted to the PQ-TLS outcome, so percentages like the 93.92% infra-managed figure are observations under that taxonomy rather than a circular reduction. The lack of ground-truth validation for that heuristic (§4.4, §5.2) is a correctness/robustness risk, which the paper itself does not claim to resolve, but it is not circularity. The only self-citation is reference [72] in §3.2, supporting the background statement that 'a substantial fraction of Internet traffic is served by large-scale CDNs and managed hosting providers'; that claim is additionally supported by refs [36,39,44] and is peripheral to the paper's load-bearing measurements. Thus no load-bearing circular step was found; the score reflects only the presence of a minor, non-load-bearing self-citation.

Assumptions & free parameters 0 free parameters · 6 assumptions · 0 invented entities

No free parameters or invented entities. The central claims rest on sampling, probing, and attribution assumptions; the largest uncharged debt is the unvalidated TLS-management attribution heuristic, which drives the agency and policy-alignment conclusions.

assumptions (6)
  • domain assumption DomCop Top 1M/Top 10M and ccTLD-based samples are representative of the public HTTPS ecosystem and national web presences.
    Used in §4.1 to construct all measurement targets; robustness checks with Tranco and CrUX in Appendix C partially mitigate but do not eliminate ranking bias.
  • domain assumption A TLS 1.3-only client advertising a fixed set of classical/hybrid/PQ algorithms accurately reveals server default and supported configurations.
    Core probing methodology in §4.3; servers may behave differently for other client profiles, and the exact client algorithm list is not fully specified in the paper.
  • domain assumption The stable panel of domains completing TLS 1.3 from all 11 vantage points in all 3 rounds is a valid basis for longitudinal adoption and policy-alignment conclusions.
    Defined at the start of §5; excludes 31.55% of scanned domains, so headline percentages are conditional on successful TLS 1.3 connectivity.
  • domain assumption The managed-vs-owner-managed attribution labels in §4.4 are accurate enough for the agency conclusions.
    No validation set, error rates, or ground-truth comparison is provided, yet RQ2/RQ3/RQ5 rely on these labels for the central 'infrastructure-driven adoption' narrative.
  • domain assumption Network noise in paired handshakes spaced roughly four hours apart is unbiased with respect to the PQ-versus-classical comparison.
    Differential latency methodology in §4.3; no statistical test for time-of-day, routing, or load-balancing asymmetries between the paired measurements is reported.
  • domain assumption The eight surveyed national/regional policy documents capture the relevant PQC transition landscape for the policy-alignment analysis.
    Selection criteria in §3 and Appendix B are based on NIST Round 1 submissions and GDP, but countries with active domestic PQC programs (e.g., China, Korea) are excluded from the quantitative alignment analysis.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Mind the Gap: Policy vs Reality in Post-Quantum TLS Deployment." pith.science (2026). https://pith.science/paper/5VXYWEJG

@misc{pith2026260729005,
  author       = {Pith},
  title        = {Pith review of: Mind the Gap: Policy vs Reality in Post-Quantum TLS Deployment},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5VXYWEJG}},
  note         = {Machine review of arXiv:2607.29005}
}
read the original abstract

Post-quantum cryptography (PQC) has evolved from a long-term planning concern into an operational priority. Following NIST's standardization of PQC, governments and standard bodies published transition roadmaps outlining migration timelines, priority sectors, and deployment strategies. However, our survey of these policies reveals substantial divergence in technical prescriptions and urgency. It remains unclear how widely PQC has been adopted in practice and how policy differences translate into observable deployment outcomes. To address this gap, we present the first longitudinal measurement study of post-quantum TLS (PQ-TLS) adoption. By establishing more than 2 billion TLS handshakes, we analyze cryptographic negotiation behavior across 1 million domains from 11 globally distributed vantage points. Despite varied policy guidance, we observe configuration convergence: PQ-TLS deployment overwhelmingly centers on a single hybrid construction, and much of the apparent progress is driven by managed infrastructure providers. National timelines and sectoral priorities show limited correspondence with observed deployment patterns. Contrary to early experimental studies suggesting measurable overhead, we find that PQ-TLS introduces no meaningful latency increase in Internet settings, although it is frequently deployed alongside legacy TLS configurations. Together, these findings highlight a gap between policy expectations and early deployment reality, and provide empirical insight to inform more grounded PQ-TLS transition.

Figures

Figures reproduced from arXiv: 2607.29005 by the authors.

Figure 1
Figure 1. PQ-TLS adoption by management attribution. [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. Infrastructure concentration of PQ-TLS deployment by March 2026. [PITH_FULL_IMAGE:figures/full_fig_p008_2.png] view at source ↗
Figure 3
Figure 3. PQ-TLS adoption across sensitive sectors and Jurisdictions (March 2026) [PITH_FULL_IMAGE:figures/full_fig_p009_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Per-domain handshake latency difference Δ𝑇 =𝑇hybrid −𝑇classical for X25519MLKEM768 relative to X25519. not result in a meaningful increase in TLS handshake latency. As shown in [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: PQ-TLS Adoption Trends Across All SafeDNS Categories [PITH_FULL_IMAGE:figures/full_fig_p019_5.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

79 extracted references · 2 linked inside Pith

  1. [1]

    Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, and Paul Zimmermann

    David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Béguelin, and Paul Zimmermann

  2. [2]

    National Security Agency. 2024. The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ. https://media.defense.gov/2022/Sep/07/2003071836/-1/- 1/0/CSI_CNSA_2.0_FAQ_.PDF. [Accessed 27-11-2025]

  3. [3]

    Nadeem Ahmed, Lei Zhang, and Aryya Gangopadhyay. 2025. A Survey of Post-Quantum Cryptography Support in Cryptographic Libraries. arXiv:2508.16078 [cs.CR] https://arxiv.org/abs/2508.16078

  4. [4]

    Akamai. 2025. Akamai Enables Post-Quantum Cryptography on the Edge. https://www.akamai.com/blog/security/akamai-enables-post- quantum-cryptography-edge. [Accessed 13-12-2025]

  5. [5]

    Johanna Amann, Oliver Gasser, Quirin Scheitle, Lexi Brent, Georg Carle, and Ralph Holz. 2017. Mission accomplished? HTTPS se- curity after diginotar. InProceedings of the 2017 Internet Measure- ment Conference (IMC ’17). Association for Computing Machinery. doi:10.1145/3131365.3131401

  6. [6]

    ANSSI. 2023. ANSSI views on the Post-Quantum Cryptography tran- sition. https://messervices.cyber.gouv.fr/documents-guides/follow_ up_position_paper_on_post_quantum_cryptography.pdf. [Accessed 11-26-2025]

  7. [8]

    Australian Signals Directorate and Australian Cyber Security Centre

  8. [9]

    Michael Bailey, David Dittrich, Erin Kenneally, and Doug Maughan

Show all 79 references
  1. [10]

    Kaveh Bashiri, Scott Fluhrer, Stefan-Lukas Gazdag, Daniel Van Geest, and Stavros Kousidis. 2025. Internet X.509 Public Key Infrastructure – Algorithm Identifiers for the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA). RFC 9909. https://www.rfc-editor.org/info/ rfc9909

  2. [11]

    https://www

    Planning for post-quantum cryptography. https://www. cyber.gov.au/sites/default/files/2025-09/Planning%20for%20post- quantum%20cryptography%20%28September%202025%29.pdf. Accessed: 2025-11-23

  3. [12]

    Chromium Blog. [n. d.]. Advancing Our Amazing Bet on Asymmetric Cryptography — blog.chromium.org. https://blog.chromium.org/2024/ 05/advancing-our-amazing-bet-on-asymmetric.html. [Accessed 23- 03-2026]

  4. [13]

    National Cyber Security Centre. 2024. Next steps in preparing for post- quantum cryptography. https://www.ncsc.gov.uk/whitepaper/next- steps-preparing-for-post-quantum-cryptography. [Accessed 26-11- 2025]

  5. [14]

    National Cyber Security Centre. 2025. Timelines for migration to post-quantum cryptography. https://www.ncsc.gov.uk/guidance/pqc- migration-timelines. [Accessed 26-11-2025]

  6. [15]

    Benjamin Beurdouche, Karthikeyan Bhargavan, Antoine Delignat- Lavaud, Cédric Fournet, Markulf Kohlweiss, Alfredo Pironti, Pierre- Yves Strub, and Jean Karim Zinzindohoue. 2015. A Messy State of the Union: Taming the Composite State Machines of TLS. In2015 IEEE Symposium on Sec...

  7. [16]

    Cert-IN and SISA. 2025. Transition to Quantum Cyber Readi- ness. https://static.pib.gov.in/WriteReadData/specificdocs/documents/ 2025/jul/doc2025714585911.pdf. [Accessed 27-11-2025]

  8. [17]

    Institute of Commercial Cryptography Standards China. [n. d.]. Next Generation Commercial Cryptographic Algorithms Program (NGCC). https://www.niccs.org.cn/en/. [Accessed 05-12-2025]

  9. [18]

    Google Chrome. [n. d.]. Overview of CrUX | Chrome UX Report. https://developer.chrome.com/docs/crux. [Accessed 08-03-2026]

  10. [19]

    NIST Computer Security Resource Centre. 2017. Round 1 Submissions - Post-Quantum Cryptography. https: //csrc.nist.gov/projects/post-quantum-cryptography/post-quantum- cryptography-standardization/round-1-submissions. [Accessed 11-11-2025]

  11. [20]

    European Commission. 2025. A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography. https://digital-strategy.ec.europa.eu/en/library/coordinated- implementation-roadmap-transition-post-quantum-cryptography. [Accessed 11-28-2025]

  12. [21]

    Common Crawl. [n. d.]. Common Crawl - Open Repository of Web Crawl Data. https://commoncrawl.org. [Accessed 25-03-2026]

  13. [22]

    Alex Halderman

    Zakir Durumeric, Michael Bailey, and J. Alex Halderman. 2014. An Internet-Wide View of Internet-Wide Scanning. In23rd USENIX Secu- rity Symposium (USENIX Security 14). USENIX Association

  14. [23]

    Cloudflare. 2025. State of the post-quantum Internet in 2025. https: //blog.cloudflare.com/pq-2025. [Accessed 28-12-2025]

  15. [24]

    Alex Halderman

    Zakir Durumeric, Eric Wustrow, and J. Alex Halderman. 2013. ZMap: Fast Internet-wide Scanning and Its Security Applications. In22nd USENIX Security Symposium (USENIX Security 13). USENIX Associa- tion

  16. [25]

    Competition

    NIST Dustin Moody. 2017. THE SHIP HAS SAILED: The NIST Post-Quantum Crypto “Competition”. https://csrc.nist.gov/csrc/ media/projects/post-quantum-cryptography/documents/asiacrypt- 2017-moody-pqc.pdf. [Accessed 11-11-2025]

  17. [26]

    Adrienne Porter Felt, Richard Barnes, April King, Chris Palmer, Chris Bentzel, and Parisa Tabriz. 2017. Measuring HTTPS Adoption on the Web. In26th USENIX Security Symposium (USENIX Security 17). USENIX Association

  18. [27]

    Alex Halderman

    Zakir Durumeric, James Kasten, Michael Bailey, and J. Alex Halderman

  19. [28]

    Canadian Centre for Cyber Security. [n. d.]. Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B information - ITSP.40.111. https://www.cyber.gc.ca/en/guidance/cryptographic- algorithms-unclassified-protected-protected-b-information- itsp40111. [Accessed 05...

  20. [29]

    Canadian Centre for Cyber Security. [n. d.]. Roadmap for the migra- tion to post-quantum cryptography for the Government of Canada (ITSM.40.001). https://www.cyber.gc.ca/en/guidance/roadmap- migration-post-quantum-cryptography-government-canada- itsm40001. [Accessed 05-12-2025]

  21. [30]

    Bundesamt für Sicherheit in der Informationstechnik (BSI). [n. d.]. BSI – Technical Guideline. https://www.bsi.bund.de/SharedDocs/ Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR- 02102-1.pdf?__blob=publicationFile&v=7. [Accessed 08-01-2026]. 14 Mind the Gap: Polic...

  22. [31]

    Bundesamt für Sicherheit in der Informationstechnik (BSI). 2024. Securing Tomorrow, Today: Transitioning to Post-Quantum Cryp- tography. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/ Crypto/PQC-joint-statement.pdf?__blob=publicationFile&v=5. [Ac- cessed 26-12-2025]

  23. [32]

    Konstantin Fischer, Ivana Trummová, Phillip Gajland, Yasemin Acar, Sascha Fahl, and Angela Sasse. 2024. The Challenges of Bringing Cryptography from Research Papers to Products: Results from an Interview Study with Experts. In33rd USENIX Security Symposium (USENIX Security 24)...

  24. [33]

    Google. 2025. Post-quantum cryptography (PQC) — cloud.google.com. https://cloud.google.com/security/resources/post-quantum- cryptography. [Accessed 11-03-2026]

  25. [34]

    CloudFlare Google. 2019. The TLS Post-Quantum Experiment. https: //blog.cloudflare.com/the-tls-post-quantum-experiment/. [Accessed 13-12-2025]

  26. [35]

    World Bank Group. [n. d.]. World Bank Open Data. https://data.worldbank.org/indicator/NY.GDP.MKTP.CD?most_ recent_value_desc=true. [Accessed 11-11-2025]

  27. [36]

    Rumaisa Habib, Kimberly Ruth, Gautam Akiwate, and Zakir Du- rumeric. 2025. Formalizing Dependence of Web Infrastructure. In Proceedings of the ACM SIGCOMM 2025 Conference (SIGCOMM ’25). Association for Computing Machinery

  28. [37]

    Google. 2016. Experimenting with Post-Quantum Cryptogra- phy. https://security.googleblog.com/2016/07/experimenting-with- post-quantum.html. [Accessed 13-12-2025]

  29. [38]

    Ralph Holz, Lothar Braun, Nils Kammenhuber, and Georg Carle. 2011. The SSL Landscape: A Thorough Analysis of the X.509 PKI Using Active and Passive Measurements. InProceedings of the 11th ACM SIGCOMM Conference on Internet Measurement (IMC ’11). Association for Computing Machinery

  30. [39]

    Ralph Holz, Jens Hiller, Johanna Amann, Abbas Razaghpanah, Thomas Jost, Narseo Vallina-Rodriguez, and Oliver Hohlfeld. 2020. Tracking the deployment of TLS 1.3 on the web: a story of experimentation and centralization.SIGCOMM Comput. Commun. Rev.(2020). doi:10.1145/ 3411740.3411742

  31. [40]

    The White House. 2022. National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems. https://irp.fas.org/offdocs/ nsm/nsm-10.pdf. [Accessed 27-11-2025]

  32. [41]

    ISO/IEC. [n. d.]. ISO/IEC JTC 1/SC 27 WG2 PQC work program. https: //committee.iso.org/sites/jtc1sc27/home/wg2.html. [Accessed 12-01- 2026]

  33. [42]

    Marcella Hastings, Joshua Fried, and Nadia Heninger. 2016. Weak Keys Remain Widespread in Network Devices. InProceedings of the 2016 Internet Measurement Conference (IMC ’16). Association for Computing Machinery. doi:10.1145/2987443.2987486

  34. [43]

    Paterson, Narseo Vallina-Rodriguez, and Juan Caballero

    Platon Kotzias, Abbas Razaghpanah, Johanna Amann, Kenneth G. Paterson, Narseo Vallina-Rodriguez, and Juan Caballero. 2018. Coming of Age: A Longitudinal Study of TLS Deployment. InProceedings of the Internet Measurement Conference 2018 (IMC ’18). Association for Computing Mach...

  35. [44]

    Hyunwoo Lee, Doowon Kim, and Yonghwi Kwon. 2021. TLS 1.3 in Practice:How TLS 1.3 Contributes to the Internet. InProceedings of the Web Conference 2021 (WWW ’21). Association for Computing Machinery. doi:10.1145/3442381.3450057

  36. [45]

    Joonhee Lee, Hyunwoo Lee, Jongheon Jeong, Doowon Kim, and Ted Taekyoung Kwon. 2021. Analyzing Spatial Differences in the TLS Security of Delegated Web Services. InProceedings of the 2021 ACM Asia Conference on Computer and Communications Security (ASIA CCS ’21). Association fo...

  37. [46]

    Bailey, Angelos D

    Zane Ma, Aaron Faulkenberry, Thomas Papastergiou, Zakir Du- rumeric, Michael D. Bailey, Angelos D. Keromytis, Fabian Monrose, and Manos Antonakakis. 2023. Stale TLS Certificates: Investigating Precarious Third-Party Access to Valid TLS Keys. InProceedings of the 2023 ACM on In...

  38. [47]

    Liz Izhikevich, Renata Teixeira, and Zakir Durumeric. 2022. Predicting IPv4 services across all ports. InProceedings of the ACM SIGCOMM 2022 Conference (SIGCOMM ’22). Association for Computing Machinery. doi:10.1145/3544216.3544249

  39. [48]

    Ministry of Communications Government of India. 2025. Migration to Post Quantum Cryptography. https://www.tec.gov.in/pdf/TR/Final% 20technical%20report%20on%20migration%20to%20PQC%2028-03- 25.pdf. [Accessed 27-11-2025]

  40. [49]

    National Institute of Standards and Technology (NIST). 2024. Stateless Hash-Based Digital Signature Standard. doi:10.6028/NIST.FIPS.205

  41. [50]

    National Institute of Standards, Technology (NIST), Gorjan Alagic, Quynh Dang, Dustin Moody, Angela Robinson, Hamilton Silberg, and Daniel Smith-Tone. 2024. Module-Lattice-Based Key-Encapsulation Mechanism Standard. doi:10.6028/NIST.FIPS.203

  42. [51]

    National Institute of Standards, Technology (NIST), Thinh Dang, Jacob Lichtinger, Yi-Kai Liu, Carl Miller, Dustin Moody, Rene Peralta, Ray Perlner, and Angela Robinson. 2024. Module-Lattice-Based Digital Signature Standard. doi:10.6028/NIST.FIPS.204

  43. [52]

    Michele Mosca. 2018. Cybersecurity in an Era with Quantum Com- puters: Will We Be Ready?IEEE Security & Privacy16, 5 (2018), 38–41. doi:10.1109/MSP.2018.3761723

  44. [53]

    Christian Paquin, Douglas Stebila, and Goutam Tamvada. 2020. Bench- marking post-quantum cryptography in TLS. InProc. 11th International Conference on Post-Quantum Cryptography (PQCrypto) 2020 (LNCS). Springer

  45. [54]

    Victor Pochat, Tom Van Goethem, Samaneh Tajalizadehkhoob, Maciej Korczynski, and Wouter Joosen. 2019. Tranco: A Research-Oriented Top Sites Ranking Hardened Against Manipulation. doi:10.14722/ndss. 2019.23386

  46. [55]

    CloudFlare Radar. [n. d.]. Data Explorer | Cloudflare Radar. https://radar.cloudflare.com/explorer?dataSet=http&groupBy=post_ quantum. [Accessed 12-12-2025]

  47. [56]

    2025.Post-Quantum Cryptography Recommendations for TLS-based Applications

    Tirumaleswar Reddy.K and Hannes Tschofenig. 2025.Post-Quantum Cryptography Recommendations for TLS-based Applications. Internet- Draft draft-ietf-uta-pqc-app-00. Internet Engineering Task Force. https://datatracker.ietf.org/doc/draft-ietf-uta-pqc-app/00/ Work in Progress

  48. [57]

    OpenSSL Library. 2025. OpenSSL 3.5 Final Release - Live | OpenSSL Library — openssl-library.org. https://openssl-library.org/post/2025- 04-08-openssl-35-final-release/. [Accessed 29-03-2026]

  49. [58]

    Quantum resistant cryptography research group. [n. d.]. KPQC. https: //kpqc.or.kr/. [Accessed 05-12-2025]

  50. [59]

    Montenegro, Antonio Muoz, and Davide Ferraris

    Ruben Rios, José A. Montenegro, Antonio Muoz, and Davide Ferraris

  51. [60]

    Kimberly Ruth, Aurore Fass, Jonathan Azose, Mark Pearson, Emma Thomas, Caitlin Sadowski, and Zakir Durumeric. 2022. A world wide view of browsing the world wide web. InProceedings of the 22nd ACM Internet Measurement Conference (IMC ’22). Association for Computing Machinery. d...

  52. [61]

    Kimberly Ruth, Deepak Kumar, Brandon Wang, Luke Valenta, and Zakir Durumeric. 2022. Toppling top lists: evaluating the accuracy of popular website lists. InProceedings of the 22nd ACM Internet Measure- ment Conference (IMC ’22). Association for Computing Machinery

  53. [62]

    Eric Rescorla. 2018. The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446

  54. [63]

    Amazon Web Services. 2025. Bringing quantum-resistance to AWS ser- vices and customers. https://aws.amazon.com/security/post-quantum- cryptography/. [Accessed 12-12-2025]

  55. [64]

    P.W. Shor. 1994. Algorithms for quantum computation: discrete loga- rithms and factoring. InProceedings 35th Annual Symposium on Foun- dations of Computer Science

  56. [65]

    Toward the Quantum-Safe Web: Benchmarking Post-Quantum TLS.IEEE Network(2025)

  57. [66]

    Markus Sosnowski, Florian Wiedner, Eric Hauser, Lion Steger, Dim- itrios Schoinianakis, Sebastian Gallenmüller, and Georg Carle. 2023. The Performance of Post-Quantum TLS 1.3. InCompanion of the 19th International Conference on Emerging Networking EXperiments and Technologies ...

  58. [67]

    Markus Sosnowski, Florian Wiedner, Eric Hauser, Lion Steger, Dim- itrios Schoinianakis, Sebastian Gallenmüller, and Georg Carle. 2023. The Performance of Post-Quantum TLS 1.3. InCompanion of the 19th International Conference on Emerging Networking EXperiments and Technologies ...

  59. [68]

    Safe DNS. [n. d.]. List of SafeDNS Categories — SafeDNS docs. https://docs.safedns.com/books/installation-guides/page/list-of- safedns-categories. [Accessed 25-03-2026]. 15 Wickramasinghe et al

  60. [69]

    Indian Computer Emergency Response Team. [n. d.]. Guidelines on Information Security Practices for Government Entities. https://www. cert-in.org.in/PDF/guidelinesgovtentities.pdf. [Accessed 05-12-2025]

  61. [70]

    Iraklis Tzinos, Konstantinos Limniotis, and Nicholas Kolokotronis

  62. [71]

    Dimitrios Sikeridis, Panos Kampanakis, and Michael Devetsikiotis

  63. [72]

    post-quantum cryptography

    Nimesha Wickramasinghe, Mohamed Nabeel, Kenneth Thilakaratne, Chamath Keppitiyagama, and Kasun De Zoysa. 2021. Un- covering IP Address Hosting Types Behind Malicious Websites. arXiv:2111.00142 [cs.CR] https://arxiv.org/abs/2111.00142 Ethics Internet-wide scanning is a well-est...

  64. [75]

    2025.Hybrid key exchange in TLS 1.3

    Douglas Stebila, Scott Fluhrer, and Shay Gueron. 2025.Hybrid key exchange in TLS 1.3. Internet-Draft draft-ietf-tls-hybrid-design-14. Internet Engineering Task Force. https://datatracker.ietf.org/doc/ draft-ietf-tls-hybrid-design/14/ Work in Progress

  65. [79]

    National Cyber Security Centre UK. [n. d.]. Using TLS to protect data. https://www.ncsc.gov.uk/guidance/using-tls-to-protect-data. [Accessed 05-12-2025]

  66. [2012]

    The Menlo Report.IEEE Security and Privacy(2012). doi:10. 1109/MSP.2012.52

  67. [2013]

    InProceedings of the 2013 Conference on Internet Measurement Conference (IMC ’13)

    Analysis of the HTTPS certificate ecosystem. InProceedings of the 2013 Conference on Internet Measurement Conference (IMC ’13). Association for Computing Machinery. doi:10.1145/2504730.2504755

  68. [2015]

    InProceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS ’15)

    Imperfect Forward Secrecy: How Diffie-Hellman Fails in Prac- tice. InProceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS ’15). Association for Computing Machinery. doi:10.1145/2810103.2813707

  69. [2020]

    InProceedings of the 27th NDSS Symposium (NDSS 2020)

    Post-Quantum Authentication in TLS 1.3: A Performance Study. InProceedings of the 27th NDSS Symposium (NDSS 2020). doi:10.14722/ ndss.2020.24203

  70. [2022]

    Evaluating the performance of post-quantum secure algorithms in the TLS protocol.Journal of Surveillance, Security and Safety(2022)

  71. [2025]

    https://www.cyber.gov.au/sites/default/files/2025-07/22.%20ISM%20- %20Guidelines%20for%20cryptography%20%28June%202025%29.pdf

    Information security manual: Guidelines for cryptography. https://www.cyber.gov.au/sites/default/files/2025-07/22.%20ISM%20- %20Guidelines%20for%20cryptography%20%28June%202025%29.pdf. Accessed: 2025-11-23

Pith tools

Reviewed August 3, 2026 · model on record in the stance chip above.