- The paper quantifies production-readiness gaps across nine PQC libraries and introduces quantum-safe, reducing hybrid KEM integration from about 45 lines to three while achieving a 243 µs median handshake.
- The library makes hybrid cryptography the default, supports ML-KEM-768 and Ed25519 with ML-DSA-65, and adds versioned CBOR keys, TLS, X.509, JWT, and migration-oriented protocol helpers.
- Benchmarks show only a 4.9% throughput decline from 100 to 5,000 concurrent users and a 6.2× build-optimization speedup, while CoV screening indicates stable ML-KEM decapsulation but does not replace formal side-channel testing.
The finalisation of FIPS 203, 204, and 205 in August 2024 settled the algorithmic questions of post-quantum cryptography (PQC), but left open what the author terms the "production gap": hybrid combiners, versioned key formats, protocol helpers, and migration tooling. The paper under review, "quantum-safe: Bridging the Post-Quantum Production Gap with a Hybrid-by-Default Python Cryptography Library" (2605.17061), addresses this gap on two fronts. First, it presents a systematic evaluation of nine PQC libraries across eight production-readiness dimensions, quantifying shortfalls in hybrid KEM support, migration tooling, and protocol integration. Second, it introduces quantum-safe, a Python library that implements a hybrid-by-default API over liboqs and RustCrypto backends, accompanied by a statistically rigorous benchmark study covering latency, concurrency, and timing variance.
The production gap analysis
The paper evaluates nine actively maintained libraries — liboqs-python, pyca/cryptography, liboqs-js, noble-post-quantum, pqcrypto, RustCrypto ml-*, oqs (Rust), cloudflare/circl, and Bouncy Castle — against eight dimensions using a ternary Full/Partial/None rubric, with scores assigned from documentation, source code, and package metadata as of March 2026. Three dimensions fall below 35% coverage:
| Dimension |
Coverage (Full + Partial) |
| Hybrid KEM |
22% (11% Full) |
| Migration path |
22% |
| Protocol layer |
33% |
Only cloudflare/circl provides a built-in X25519 + ML-KEM combiner; no library other than Bouncy Castle (partially) offers migration tooling such as keypair upgrades or classical-import scanning. The paper argues this is the most consequential gap because IETF draft-ietf-tls-hybrid-design specifies precise domain-separation and key-binding requirements for combiners, and prior API-usability work [georgiev2012most; lazar2014why] shows that manual composition of cryptographic primitives is routinely incorrect. A caveat is stated plainly: the scores derive from public metadata, maintainers may dispute Partial classifications, and the boundary judgments are documented but ultimately subjective.
Library design
quantum-safe rests on five principles: hybrid by default (opt-out of classical-only requires an explicit flag), backend agnosticism via an abstract backend layer (liboqs default, RustCrypto via PyO3), protocol readiness (TLS helpers, hybrid X.509 certificates per the composite-signatures draft, CBOR envelope encryption, JWT), migration-first versioned key serialisation in CBOR with an explicit version field, and safe defaults (ML-KEM-768, Ed25519 + ML-DSA-65). The headline usability claim is that the canonical hybrid KEM task shrinks from roughly 45 lines of manual combiner code in liboqs-python to three lines. This matters beyond convenience: the manual implementation leaves open HKDF salt choice, share ordering, and ciphertext framing — exactly the decisions the IETF draft resolves and application developers get wrong. The paper claims the library is the first Python implementation of composite X.509 certificates.
Benchmark methodology
All measurements use a common harness: 3,000 iterations, 100 warmup iterations, 1% outlier trimming, time.perf_counter, disabled GC, CPU pinning to cores 0–1, best of three runs. Statistics reported are median, p95, Coefficient of Variation (CoV), Welch's t-test, Cohen's d, and bootstrap 95% confidence intervals (B=2,000). Two environments run on identical hardware: ENV-2 (Docker/Linux, liboqs 0.15.0 compiled with -DOQS_DIST_BUILD=ON enabling AVX2/AVX-512) is authoritative; ENV-1 (Windows native, unoptimised MSYS2 DLL) isolates build-flag effects. One methodological concession deserves emphasis: raw timing samples were not persisted, so confidence intervals are normal approximations derived from stored summary statistics — unbiased for medians and exact for the Welch test, but weaker than full-sample bootstrapping.
Latency results
The full X25519 + ML-KEM-768 handshake completes in 243 µs median in ENV-2, versus 48 µs for classical-only X25519. Welch's test yields t≈1,298, p<10−300, Cohen's d≈33.5 — distributions that do not overlap at all. The paper correctly notes that statistical detectability is not the operative question; operational acceptability is. Contextualised against an 8–40 ms TLS 1.3 handshake, the 195 µs hybrid overhead is 0.5–2.5% of the round-trip budget, dropping below 0.2% at WAN latencies. Notably, the decomposition shows the Python combiner layer (HKDF-SHA256, PEM/CBOR serialisation) costs 37–64 µs per operation — comparable to or exceeding the underlying primitive cost — which motivates a proposed key-caching optimisation reducing handshake time to roughly 195 µs. Hybrid signature operations total approximately 510 µs.
A striking cross-environment result: ML-KEM-768 keygen differs 6.2× between builds (62.70 µs vs 10.16 µs), attributable entirely to AVX2/AVX-512 code paths enabled by a single CMake flag rather than any OS effect. The implication for deployment is concrete: organisations compiling liboqs from source on Linux obtain the optimised paths automatically, while Windows deployments relying on generic DLLs pay a substantial penalty.
Concurrency and GIL release
Under concurrent load from 100 to 5,000 users, throughput degrades only from 2,994 to 2,848 ops/s (4.9% across a 50× load increase). The paper presents this as the first published evidence that liboqs releases the Python GIL during C-level operations: if the GIL were held, throughput would collapse to roughly 0.8 ops/s at 5,000 threads, whereas 2,848 ops/s is observed — about 3,500× higher. Corroborating evidence is that ENV-1 and ENV-2, despite a 2.4× per-operation latency difference, converge to nearly identical throughput at 5,000 users (2,842 vs 2,848 ops/s), indicating that thread scheduling, not cryptography, bounds concurrent throughput. These measurements use Python 3.12 with the GIL enabled; behaviour under free-threaded Python 3.13+ (PEP 703) is explicitly left open.
CoV as a timing side-channel proxy
The paper introduces CoV as a first-order timing screen for PQC operations, using AES-256-GCM (CoV = 2.1%) as a constant-time noise floor. Key findings:
- ML-KEM-768 decapsulation: CoV = 3.9%, only 1.8 percentage points above the noise floor and within Hyper-V scheduling uncertainty — consistent with FIPS 203 constant-time requirements.
- ML-DSA-65 signing: CoV = 51.5%, p95/median ratio 2.4. The paper argues this is expected and correct: FIPS 204 hedged signing uses rejection sampling whose iteration count follows a geometric distribution driven by fresh randomness, independent of key and message, hence not exploitable.
- HybridKEM operations show CoV of 5–6%, attributed to OS scheduler noise in the Python serialisation layer.
The paper is appropriately careful here: CoV is a necessary but not sufficient condition for constant-time behaviour. It cannot rule out cache-timing attacks on public data, and formal verification via dudect or ct-verif applied to the underlying C code remains required for stronger guarantees. The claim that this methodology has not previously been applied to PQC library evaluation appears sound given the related-work survey, though its sensitivity relative to established statistical tests (e.g., t-tests on fixed-vs-random input classes, as in dudect) is not empirically characterised.
Limitations and open questions
The paper concedes several constraints. All benchmarks come from a single physical host under WSL2/Hyper-V virtualisation, so absolute figures are hardware-specific; only relative relationships are claimed to generalise. The WASM backend target is planned but unreleased, leaving principle P2 partially realised. SLH-DSA (FIPS 205) is absent, acknowledged as important as a hedge against lattice assumptions being weakened, with no timeline committed. The gap-analysis rubric involves judgment calls that library maintainers may contest. Open questions include whether the CoV screen detects realistic secret-dependent leakage in higher-level bindings, how the concurrency profile changes under free-threaded CPython, and whether the key-caching optimisation preserves security properties across session-reuse patterns.
Conclusion
This paper makes two complementary contributions: a reproducible quantification of the PQC production gap across nine libraries, and a working Python library plus benchmark study demonstrating that hybrid post-quantum key exchange in Python is operationally cheap (243 µs per handshake, ~0.5–2.5% of a TLS budget), genuinely concurrent (GIL released by liboqs), and timing-stable where the standards require it. The strongest claims — near-flat throughput under 50× load increase and the 6.2× build-flag speedup — are well supported by the presented evidence, while the CoV methodology is offered honestly as a screening tool rather than a proof. Together with its companion static-analysis tool, the work supplies a coherent Python-native migration toolchain; the remaining barrier it identifies is adoption awareness rather than technical capability.
