pith. sign in

arxiv: 2605.17061 · v1 · pith:CNQ7TBJ4new · submitted 2026-05-16 · 💻 cs.CR · quant-ph

quantum-safe: Bridging the Post-Quantum Production Gap with a Hybrid-by-Default Python Cryptography Library

Animesh Shaw This is my paper

Pith reviewed 2026-05-20 15:41 UTC · model grok-4.3

classification 💻 cs.CR quant-ph
keywords post-quantum cryptographyhybrid KEMPython libraryproduction readinessML-KEMperformance measurementside-channel analysiscoefficient of variation
0
0 comments X

The pith

The quantum-safe Python library closes the post-quantum production gap by scoring full marks on every production-readiness dimension and cutting hybrid KEM combiner code from 45 lines to three.

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

After the 2024 standardization of ML-KEM, ML-DSA and SLH-DSA, the remaining obstacles to real-world use are hybrid combiners, versioned key formats, protocol helpers and migration tools. The paper evaluates nine existing PQC libraries against eight production-readiness dimensions and finds that hybrid KEM support, migration tooling and protocol integration remain below 35 percent coverage in most cases. quantum-safe is presented as a hybrid-by-default library that reaches full coverage on all eight dimensions while supplying concrete performance numbers and a simple statistical check for timing variation. A sympathetic reader cares because these gaps currently force developers to write error-prone custom glue code that can introduce security weaknesses during the transition to quantum-resistant cryptography.

Core claim

quantum-safe supplies a complete, hybrid-by-default Python API that implements the missing production layer for post-quantum cryptography, achieving full scores across the eight production-readiness dimensions while reducing manual hybrid KEM combiner code from 45 lines to three lines and delivering reproducible measurements of sub-millisecond handshake latency and a coefficient-of-variation metric for timing side-channel assessment.

What carries the argument

The hybrid-by-default API that encapsulates combiner logic, versioned key formats, protocol helpers and migration tooling inside three-line calls.

If this is right

  • Hybrid key exchanges can be added to Python code with far lower risk of insecure custom combiner implementations.
  • Measured handshake times of roughly 243 microseconds leave ample headroom inside typical TLS 1.3 round-trip budgets.
  • Throughput at thousands of concurrent users shows only single-digit percentage degradation, confirming practical scalability.
  • The coefficient-of-variation check gives developers a lightweight way to screen for unexpected timing variation before formal constant-time audits.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Similar hybrid-by-default wrappers could be built for other languages to reduce the same production gap outside Python.
  • The CoV timing metric might be tested on classical algorithms to see whether it catches known side-channel issues.
  • Periodic re-evaluation of the eight dimensions will be needed as new standards and deployment patterns emerge.

Load-bearing premise

The eight chosen production-readiness dimensions accurately and comprehensively capture everything required for safe real-world deployment of PQC libraries.

What would settle it

A documented case in which a library scoring full on the eight dimensions nevertheless fails in production because of a missing requirement such as hardware-specific integration or regulatory compliance not covered by those dimensions.

Figures

Figures reproduced from arXiv: 2605.17061 by Animesh Shaw.

Figure 1
Figure 1. Figure 1: Production readiness matrix for nine PQC libraries across eight [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Module architecture of quantum-safe. Application code interacts only with HybridKEM and HybridSign. Protocol helpers (tls, x509, envelope) and the audit module sit above a backend abstraction layer that currently exposes liboqs-python and RustCrypto. The five design principles are directly reflected in the module structure shown in [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Lines of code required for a complete hybrid KEM operation. liboqs [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Stacked bar decomposition of hybrid KEM latency. The Python [PITH_FULL_IMAGE:figures/full_fig_p006_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: (a) Throughput vs concurrency; (b) per-user latency vs concurrency. [PITH_FULL_IMAGE:figures/full_fig_p007_5.png] view at source ↗
Figure 7
Figure 7. Figure 7: Latency percentile profile (p50, p95, p99) for all KEM operations in [PITH_FULL_IMAGE:figures/full_fig_p009_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: ENV-1 (Windows 11) vs ENV-2 (Docker/Linux) on the same hardware. [PITH_FULL_IMAGE:figures/full_fig_p009_8.png] view at source ↗
read the original abstract

The August 2024 finalisation of FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) closed the algorithmic gap in post-quantum cryptography (PQC). The production gap -- hybrid combiners, versioned key formats, protocol helpers, and migration tooling -- remains open. We present quantum-safe, a Python library that closes all three critical gaps we identify, and a systematic evaluation of the nine-library ecosystem that quantifies them. We score nine PQC libraries across eight production-readiness dimensions. Three dimensions have coverage below 35%: hybrid KEM support (11%), migration tooling (22%), and protocol integration (33%). quantum-safe scores Full on all eight. The full API reduces the hybrid KEM task from 45 lines of manual combiner code to three lines, directly lowering the risk of insecure combiner implementations. We report the first statistically rigorous per-operation overhead measurement for a Python hybrid PQC library (3,000 iterations, CPU-pinned, bootstrapped 95% confidence intervals). A full X25519 + ML-KEM-768 handshake completes in 243 {\mu}s under Docker/Linux -- 0.5--2.5% of a typical TLS 1.3 round-trip budget. At 5,000 concurrent users, throughput holds at 2,848 ops/s with only 4.9% degradation versus the single-user baseline, confirming that liboqs releases the Python GIL during C-level operations. We introduce Coefficient of Variation (CoV) as a practical timing side-channel proxy across all FIPS 203/204 operations. ML-KEM-768 decapsulation achieves CoV = 3.9%, within the AES-256-GCM noise floor (2.1%). ML-DSA-65 signing shows CoV = 51.5%, expected from FIPS 204 rejection sampling, not a side-channel. This CoV methodology has not previously been applied to PQC library evaluation and provides a lightweight complement to formal constant-time verification tools. All results are reproducible via a single Docker command.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The manuscript presents quantum-safe, a Python library for post-quantum cryptography that implements hybrid-by-default KEMs, versioned key formats, protocol helpers, and migration tooling to address the production gap left after FIPS 203/204/205 finalization. It evaluates nine existing PQC libraries across eight production-readiness dimensions, reporting that only 11% have hybrid KEM support, 22% have migration tooling, and 33% have protocol integration; quantum-safe scores Full on every dimension. The library reduces hybrid KEM combiner code from 45 manual lines to three API calls. Performance is measured over 3,000 CPU-pinned iterations with bootstrapped 95% CIs, showing a full X25519+ML-KEM-768 handshake at 243 μs and 2,848 ops/s at 5,000 concurrent users with 4.9% degradation; Coefficient of Variation is introduced as a lightweight timing side-channel proxy, with ML-KEM-768 decapsulation at CoV=3.9%. All results are claimed reproducible via one Docker command.

Significance. If the evaluation framework and measurements are reproducible and the scoring rubric is made explicit, the work would be a useful practical contribution that quantifies concrete gaps in the current PQC ecosystem and demonstrates a low-overhead hybrid library with claimed side-channel properties. The reproducibility claim via a single Docker command and the use of bootstrapped confidence intervals are positive elements that strengthen the performance section. The CoV proxy is a novel lightweight addition to library evaluation, though its relation to formal constant-time analysis would benefit from further discussion.

major comments (3)
  1. [Production-readiness evaluation] Production-readiness evaluation section: the assignment of 'Full' scores to quantum-safe on all eight dimensions, and the comparative figures of 11% hybrid KEM coverage and 22% migration tooling coverage, rest on an unstated rubric, weighting, and per-library evidence table. Without these, the central claim that quantum-safe closes the production gap cannot be independently verified or reproduced by readers.
  2. [Performance evaluation] Performance measurement section: the 3,000-iteration methodology with CPU pinning and bootstrapped intervals is described at a high level, but data exclusion rules, exact timing harness code, and full raw data are not provided beyond the Docker command. This is load-bearing for the soundness of the overhead and scalability claims (243 μs handshake, 4.9% degradation at 5k users).
  3. [API and hybrid KEM implementation] Hybrid KEM API section: the reduction from 45 lines of manual combiner code to three lines is presented as directly lowering insecure-combiner risk, yet the manuscript does not show the internal implementation of the combiner or demonstrate that it avoids the documented pitfalls of ad-hoc hybrids. This is central to the security argument.
minor comments (2)
  1. [Introduction] The abstract refers to 'three critical gaps we identify' but the manuscript should explicitly list and number them in the introduction for clarity.
  2. [Figures] Figure captions for the performance plots should include the exact Docker image tag and commit hash used for the reported runs.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for their constructive and detailed feedback. We address each major comment below, providing clarifications and committing to specific revisions that enhance the manuscript's transparency and reproducibility without altering its core contributions.

read point-by-point responses

  1. Referee: [Production-readiness evaluation] Production-readiness evaluation section: the assignment of 'Full' scores to quantum-safe on all eight dimensions, and the comparative figures of 11% hybrid KEM coverage and 22% migration tooling coverage, rest on an unstated rubric, weighting, and per-library evidence table. Without these, the central claim that quantum-safe closes the production gap cannot be independently verified or reproduced by readers.

    Authors: We agree that the production-readiness evaluation would be strengthened by an explicit rubric and supporting evidence. In the revised manuscript, we will add a dedicated subsection detailing the scoring criteria for each of the eight dimensions (defining 'Full', 'Partial', and 'None' explicitly) along with the rationale for any weighting. We will also include a supplementary table providing per-library evidence and justifications for the reported coverage figures (11% hybrid KEM support, 22% migration tooling, 33% protocol integration). This will enable independent verification of the ecosystem gaps and the claim that quantum-safe scores Full across all dimensions. revision: yes

  2. Referee: [Performance evaluation] Performance measurement section: the 3,000-iteration methodology with CPU pinning and bootstrapped intervals is described at a high level, but data exclusion rules, exact timing harness code, and full raw data are not provided beyond the Docker command. This is load-bearing for the soundness of the overhead and scalability claims (243 μs handshake, 4.9% degradation at 5k users).

    Authors: We acknowledge that additional methodological details are required for full reproducibility of the performance results. In the revision, we will expand the performance section to specify the data exclusion rules (including any outlier handling criteria), provide the complete timing harness code used for the CPU-pinned 3,000-iteration measurements with bootstrapped confidence intervals, and include links or references to the full raw data files hosted in the repository. These additions will directly support the reported figures such as the 243 μs handshake and 4.9% degradation at 5,000 users while preserving the existing Docker-based reproduction path. revision: yes

  3. Referee: [API and hybrid KEM implementation] Hybrid KEM API section: the reduction from 45 lines of manual combiner code to three lines is presented as directly lowering insecure-combiner risk, yet the manuscript does not show the internal implementation of the combiner or demonstrate that it avoids the documented pitfalls of ad-hoc hybrids. This is central to the security argument.

    Authors: We recognize the need to substantiate the security benefits of the hybrid KEM API. While the manuscript highlights the reduction in code complexity, it does not detail the combiner internals. In the revised version, we will include a description of the combiner implementation, referencing standard hybrid constructions (e.g., those aligned with ongoing IETF hybrid designs), and explicitly discuss how it addresses common pitfalls such as improper domain separation or key mixing. Relevant source code excerpts will be added to an appendix, with the full implementation available in the library repository, to demonstrate avoidance of ad-hoc risks and reinforce the security argument. revision: yes

Circularity Check

0 steps flagged

No circularity: direct empirical scoring and measured benchmarks

full rationale

The paper's central claims rest on a comparative feature scoring of nine libraries across eight explicitly listed production-readiness dimensions and on direct runtime measurements (3,000 iterations, CPU-pinned, bootstrapped confidence intervals). These are presented as observed outcomes rather than quantities derived from the library's own equations or fitted parameters. The 45-to-3-line API reduction is a concrete code-size comparison, not a self-referential prediction. No equations, ansatzes, or uniqueness theorems appear in the provided text, and the evaluation methodology does not reduce to self-citation or redefinition of its inputs. The derivation chain is therefore self-contained against external benchmarks.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The central claim rests on standard cryptographic assumptions from FIPS standards and the premise that the chosen evaluation dimensions are the right ones for production readiness. No free parameters or new entities are introduced; the work is an engineering contribution rather than a theoretical derivation.

axioms (1)
  • domain assumption FIPS 203, 204, and 205 provide secure post-quantum algorithms suitable for hybrid use.
    The library and evaluation are built directly on these recently finalized standards as the algorithmic foundation.

pith-pipeline@v0.9.0 · 5934 in / 1410 out tokens · 52441 ms · 2026-05-20T15:41:05.853279+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

31 extracted references · 31 canonical work pages · 1 internal anchor

  1. [1]

    Module-Lattice-Based Key-Encapsulation Mechanism Standard,

    National Institute of Standards and Technology, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” NIST, Tech. Rep. FIPS 203,

    work page

  2. [2]

    title Post-quantum cryptography standards: FIPS 203, 204, 205

    [Online]. Available: https://doi.org/10.6028/NIST.FIPS.203

    work page doi:10.6028/nist.fips.203

  3. [4]

    NIST Special Publication 800-230 (Initial Public Draft), National Insti- tute of Standards and Technology (Apr 2026).https://doi.org/10.6028/NIST

    ——, “Stateless Hash-Based Digital Signature Standard,” NIST, Tech. Rep. FIPS 205, 2024. [Online]. Available: https://doi.org/10.6028/NIST. FIPS.205

    work page doi:10.6028/nist 2024

  4. [5]

    CRYSTALS – Kyber: A CCA- Secure Module-Lattice-Based KEM,

    J. Bos, L. Ducas, E. Kiltz, T. Lepoint, V . Lyubashevsky, J. M. Schanck, P. Schwabe, G. Seiler, and D. Stehlé, “CRYSTALS – Kyber: A CCA- Secure Module-Lattice-Based KEM,” in3rd IEEE European Symposium on Security and Privacy, 2018, pp. 353–367

    work page 2018

  5. [6]

    CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme,

    L. Ducas, E. Kiltz, T. Lepoint, V . Lyubashevsky, P. Schwabe, G. Seiler, and D. Stehlé, “CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme,” inIACR Transactions on Cryptographic Hardware and Embedded Systems, vol. 2018, no. 1, 2018, pp. 238–268

    work page 2018

  6. [7]

    Hybridization of NIST PQC Algorithms and Traditional Algorithms,

    D. Stebila, S. Fluhrer, and S. Gueron, “Hybridization of NIST PQC Algorithms and Traditional Algorithms,” IETF Internet-Draft draft-ietf- tls-hybrid-design-10, 2023. [Online]. Available: https://datatracker.ietf. org/doc/draft-ietf-tls-hybrid-design/

    work page 2023

  7. [8]

    The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software,

    M. Georgiev, S. Iyengar, S. Jana, R. Anubhai, D. Boneh, and V . Shmatikov, “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software,” in19th ACM Conference on Computer and Communications Security (CCS 2012), 2012, pp. 38–49

    work page 2012

  8. [9]

    Why Does Cryp- tographic Software Fail? A Case Study and Open Problems,

    D. Lazar, H. Chen, X. Wang, and N. Zeldovich, “Why Does Cryp- tographic Software Fail? A Case Study and Open Problems,” in5th Asia-Pacific Workshop on Systems (APSys 2014), 2014

    work page 2014

  9. [10]

    Cybersecurity in an Era with Quantum Computers: Will We Be Ready?

    M. Mosca, “Cybersecurity in an Era with Quantum Computers: Will We Be Ready?” IEEE Security & Privacy, pp. 38–41, 2018. IEEE TRANSACTIONS ON INFORMATION FORENSICS AND SECURITY 12

    work page 2018

  10. [11]

    Commercial National Security Algorithm Suite 2.0,

    National Security Agency, “Commercial National Security Algorithm Suite 2.0,” NSA, Tech. Rep. CNSA 2.0, 2022. [Online]. Available: https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/ CSA_CNSA_2.0_ALGORITHMS_.PDF

    work page 2022

  11. [12]

    Quantum-Safe Code Auditing: LLM-Assisted Static Analysis and Quantum-Aware Risk Scoring for Post-Quantum Cryptography Migration

    A. Shaw, “Quantum-Safe Auditor: Static Detection of Post-Quantum Cryptography Gaps in Python Codebases,” arXiv:2604.00560 [cs.CR], 2025, preprint. [Online]. Available: https://arxiv.org/abs/2604.00560

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  12. [13]

    Defending Against Future Threats: Cloudflare Goes Post-Quantum,

    D. Stebila and N. Sullivan, “Defending Against Future Threats: Cloudflare Goes Post-Quantum,” Cloudflare Blog, 2022. [Online]. Available: https://blog.cloudflare.com/post-quantum-for-all/

    work page 2022

  13. [14]

    X25519Kyber768Draft00 hybrid post-quantum key agreement in Chrome,

    P. Kampanakis and B. Westerbaan, “X25519Kyber768Draft00 hybrid post-quantum key agreement in Chrome,” The Chromium Projects, 2023. [Online]. Available: https://blog.chromium.org/2023/08/ protecting-chrome-traffic-with-hybrid.html

    work page 2023

  14. [15]

    Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems,

    P. C. Kocher, “Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems,” inAdvances in Cryptology (CRYPTO 1996), 1996, pp. 104–113

    work page 1996

  15. [16]

    Remote Timing Attacks Are Still Practical,

    B. B. Brumley and N. Tuveri, “Remote Timing Attacks Are Still Practical,” inEuropean Symposium on Research in Computer Security (ESORICS 2011), 2011, pp. 355–371

    work page 2011

  16. [17]

    Verifying Constant-Time Implementations,

    J. B. Almeida, M. Barbosa, G. Barthe, F. Dupressoir, and M. Emmi, “Verifying Constant-Time Implementations,” in25th USENIX Security Symposium, 2016, pp. 53–70. [Online]. Available: https://www.usenix. org/system/files/conference/usenixsecurity16/sec16_paper_almeida.pdf

    work page 2016

  17. [18]

    Dude, is my code constant time?

    O. Reparaz, J. Balasch, and I. Verbauwhede, “Dude, is my code constant time?” inDesign, Automation & Test in Europe (DATE 2017), 2017

    work page 2017

  18. [19]

    Understanding the Python GIL,

    D. Beazley, “Understanding the Python GIL,” inPyCon 2010, 2010. [Online]. Available: https://www.dabeaz.com/python/UnderstandingGIL. pdf

    work page 2010

  19. [20]

    Post-Quantum Key Exchange for the Internet and the Open Quantum Safe Project,

    D. Stebila and M. Mosca, “Post-Quantum Key Exchange for the Internet and the Open Quantum Safe Project,” inSelected Areas in Cryptography (SAC 2016), 2017, pp. 14–37

    work page 2016

  20. [21]

    Concise Binary Object Representation (CBOR),

    C. Bormann and P. Hoffman, “Concise Binary Object Representation (CBOR),” RFC 8949, 2020

    work page 2020

  21. [22]

    The Generalization of Student’s Problem when Several Different Population Variances are Involved,

    B. L. Welch, “The Generalization of Student’s Problem when Several Different Population Variances are Involved,”Biometrika, vol. 34, no. 1–2, pp. 28–35, 1947

    work page 1947

  22. [23]

    Cohen,Statistical Power Analysis for the Behavioral Sciences, 2nd ed

    J. Cohen,Statistical Power Analysis for the Behavioral Sciences, 2nd ed. Hillsdale, NJ: Lawrence Erlbaum Associates, 1988

    work page 1988

  23. [24]

    Bootstrap Methods: Another Look at the Jackknife,

    B. Efron, “Bootstrap Methods: Another Look at the Jackknife,”The Annals of Statistics, vol. 7, no. 1, pp. 1–26, 1979

    work page 1979

  24. [25]

    Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange,

    M. Sosnowskiet al., “Layered Performance Analysis of TLS 1.3 Handshakes: Classical, Hybrid, and Pure Post-Quantum Key Exchange,” arXiv preprint, vol. arXiv:2603.11006, 2025. [Online]. Available: https://arxiv.org/abs/2603.11006

    work page arXiv 2025

  25. [26]

    Post-Quantum TLS without Handshake Signatures,

    D. Stebila, S. Fluhrer, and S. Gueron, “Post-Quantum TLS without Handshake Signatures,” inProceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security, 2021, pp. 1461– 1480

    work page 2021

  26. [27]

    pqm4: Testing and Benchmarking NIST PQC on ARM Cortex-M4,

    M. J. Kannwischer, J. Rijneveld, P. Schwabe, and K. Stoffelen, “pqm4: Testing and Benchmarking NIST PQC on ARM Cortex-M4,” in Workshop on Attacks and Solutions in Hardware Security (ASHES),

    work page

  27. [28]

    Available: https://eprint.iacr.org/2019/844

    [Online]. Available: https://eprint.iacr.org/2019/844

    work page 2019

  28. [29]

    PQClean: Clean, Portable, Tested Implementations of Post-Quantum Cryptography,

    P. Contributors, “PQClean: Clean, Portable, Tested Implementations of Post-Quantum Cryptography,” GitHub repository, 2019. [Online]. Available: https://github.com/PQClean/PQClean

    work page 2019

  29. [30]

    Benchmarking Post-Quantum Cryptography in TLS,

    C. Paquin, D. Stebila, and G. Tamvada, “Benchmarking Post-Quantum Cryptography in TLS,” inPost-Quantum Cryptography (PQCrypto 2020), 2020, pp. 72–91

    work page 2020

  30. [31]

    Post-Quantum Lattice-Based Cryptography Implementations: A Survey,

    H. Nejatollahi, N. Dutt, S. Ray, F. Regazzoni, I. Banerjee, and R. Cam- marota, “Post-Quantum Lattice-Based Cryptography Implementations: A Survey,”ACM Computing Surveys, vol. 51, no. 6, pp. 1–41, 2019

    work page 2019

  31. [32]

    Composite Signatures for use in Internet PKI,

    M. Ounsworth, J. Gray, and M. Pala, “Composite Signatures for use in Internet PKI,” IETF Internet-Draft draft-ounsworth-pq- composite-sigs, 2024. [Online]. Available: https://datatracker.ietf.org/doc/ draft-ounsworth-pq-composite-sigs/

    work page 2024