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

arXiv:2605.17061 · cs.CR, quant-ph · Submitted 2026-05-16 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: Today's paper: "quantum-safe: Bridging the Post-Quantum Production Gap with a Hybrid-by-Default Python Cryptography Library".

Elias: The production gap in post-quantum cryptography remains open despite NIST standardizing core algorithms,

Nadia: First, who's behind it and why it matters.

Title and authors: Nadia: Moving on to the summary of "quantum-safe: Bridging the Post-Quantum Production Gap with a Hybrid-by-Default Python Cryptography Library," what we just discussed was about how this library addresses the production gap in hybrid cryptography.

Elias: Right, and what’s important is that they don't just talk about the algorithms themselves, but focus on those missing pieces like versioned key formats and protocol helpers that are crucial for real-world deployment.

Priya: I want to focus on the core mechanism: how does this library actually achieve that hybrid combination efficiently, and what does the paper say about interoperability?

Nadia: Well, the summary explains that they use a "Hybrid by default" principle, meaning you have to explicitly opt-out to use classical-only mode, which flips the burden onto the user if they want that specific behavior.

Elias: And they tackle the serialization challenge head-on because post-quantum public keys are significantly larger than their classical counterparts; for example, an ML-KEM-seven hundred sixty-eight key is one thousand one hundred eighty-four bytes compared to just thirty-two bytes for Xtwenty-five thousand five hundred nineteen <ref:2605.17061#pg2,post-quantum public keys are>.

Priya: That size difference is a major practical hurdle in terms of storage and network bandwidth, so how does the paper suggest handling that without making everything unwieldy?

Nadia: The solution they present involves using CBOR-serialised envelope formats specifically to support future upgrades and ensure interoperability between different systems.

Elias: That’s a key design choice because, as the summary notes, without a standard format, every application invents its own way of packaging those hybrid keys and algorithm identifiers.

Priya: So they are suggesting that standardization around the data structure itself is just as important as the cryptographic primitive implementation when it comes to production readiness.

Nadia: They also detail how this library integrates with protocol helpers for things like TLS configuration and X.five hundred nine certificate generation, which covers a lot of the integration friction we see in the field <ref:2605.17061#pg1>.

Elias: That moves beyond just a mathematical function; it’s about providing an entire application-layer interface that developers can actually drop into their existing frameworks.

Priya: It sounds like they are aiming to remove the cognitive load associated with building these complex cryptographic wrappers from scratch, which is a big win for researchers and engineers alike.

Nadia: And finally, they emphasize their systematic evaluation of nine PQC libraries across eight dimensions to give us that hard data on where the current ecosystem falls short.

Elias: That evaluation provides the evidence needed to justify why a solution like this library is necessary for moving forward past the theoretical stage into production reality.

The paper's summary: Nadia: Now we get into what makes this paper’s proposed solution actually better than what we have today, focusing on the explicit improvements they suggest in "quantum-safe: Bridging the Post-Quantum Production Gap with a Hybrid-by-Default Python Cryptography Library."

Elias: The primary improvement, as highlighted in page zero of that work, is how the full API dramatically simplifies the task: it reduces the hybrid KEM task from forty-five lines of manual combiner code to only three lines.

Priya: That massive reduction in implementation effort sounds like a significant practical gain, but I'm wondering about the underlying security assumptions when you condense that much code.

Nadia: The paper addresses that by enforcing a "Hybrid by default" principle, which means opting into classical-only mode requires an explicit flag to invert the burden of security back onto the user if they choose to do that.

Elias: That’s a very pragmatic way to handle it; it keeps the security posture strong unless someone actively decides they want to revert to a non-post-quantum state.

Priya: And I also noted their focus on "Backend agnostic" architecture, which lets users swap out implementations like liboqs or RustCrypto without touching the application code itself.

Nadia: That modularity is key because it means the library isn't locked into one specific underlying C library, which keeps things flexible and future-proof.

Elias: And they also prioritize a "Migration first" approach by including a scanner module designed to locate classical cryptography imports within source trees, linking directly to the Quantum-Safe Auditor mentioned in their companion work.

Priya: That proactive scanning capability is what I think gives it that strong production readiness score; it doesn't just solve the immediate problem, it helps prevent future ones by finding legacy code.

Nadia: And they also enforce "Safe defaults," defaulting to ML-KEM-seven hundred sixty-eight for KEM and Ed25519 + ML-DSA-sixty-five for signatures, which sets a high baseline security expectation.

Elias: Setting those high defaults means that if a developer forgets to configure something, the system still starts with a robust hybrid setup, which is much safer than defaulting to something weak.

Priya: It seems like the paper’s suggested improvements are less about inventing new math and more about creating an infrastructure that handles the complexity of *using* existing algorithms securely.

Nadia: Precisely, and it’s this focus on infrastructure—on combiners, versions, helpers, and migration paths—that they argue is what's missing in the current landscape.

The paper's improvements: Nadia: We’ve covered the title and authors of "quantum-safe: Bridging the Post-Quantum Production Gap with a Hybrid-by-Default Python Cryptography Library," and now we’re looking at a summary of what they actually delivered in terms of fixes.

Elias: They successfully demonstrated that by providing this library, they can close the production gap by offering hybrid key exchange, versioned formats, and protocol helpers that developers are currently missing.

Priya: From my point of view, the most impactful conclusion is that this library moves PQC from a niche research topic into a viable part of the development stack for general applications.

Nadia: It really does; it shows that integrating post-quantum security doesn't have to be an insurmountable barrier requiring deep cryptographic expertise for every developer.

Elias: And they provide concrete evidence that this isn't just theoretical; they report the first statistically rigorous per-operation overhead measurement for a Python hybrid PQC library, showing a full handshake takes two hundred forty-three microseconds under Docker/Linux.

Priya: That latency measurement is really grounding the discussion in reality; knowing it’s only about zero point one nine five milliseconds of the TLS budget gives us a clear idea of its practical impact on network performance.

Nadia: It confirms that this overhead is negligible relative to typical network latency, showing strong throughput at two thousand eight hundred forty-eight operations per second with only a small degradation during load tests <ref:2605.17061#pg0>.

Elias: So the implication is that developers can start deploying these systems knowing they have a statistically sound way to handle the complexity of hybrid cryptography without crippling their performance.

Priya: I think this work sets a clear path forward for building secure, quantum-safe software by providing the necessary tools and evaluation framework.

Conclusion: Nadia: So we’ve spent this time looking at "quantum-safe: Bridging the Post-Quantum Production Gap with a Hybrid-by-Default Python Cryptography Library," and we’re wrapping up by thinking about what all this means for us.

Elias: I agree, it really shows how crucial those missing pieces—the hybrid combiners and versioning—are when we're trying to get algorithms into the real world.

Priya: The data really showed that the current ecosystem is lagging significantly in hybrid support, which is a pretty stark reality for privacy researchers.

Nadia: Exactly, and it’s exciting because this paper gives us a tangible tool to start addressing those deficiencies immediately in our development pipelines.

Elias: If we look at the technical side, the reduction from forty-five lines of boilerplate code down to three lines is what makes this library so compelling for anyone trying to implement it.

Priya: And from a measurement standpoint, the paper provides rigorous benchmarks that show these operations are actually performing quite well, with negligible overhead in terms of network budget.

Nadia: That performance data is super important because it means we can actually deploy something hybrid without worrying about crippling latency on our services.

Elias: The timing side-channel analysis using the Coefficient of Variation also gave us some concrete evidence that the operations are stable enough for practical use, which is a big deal.

Priya: I think what this paper really delivers to the broader community is a standardized way to approach PQC integration that accounts for real-world deployment challenges like versioning and migration.

Nadia: It’s about moving past just having the math work and actually building the infrastructure around it so we don't end up with these production gaps later.

Elias: I feel like this library, in its design principles, offers a very strong foundation for future work in AI-driven PQC migration agents.

Priya: I just think having tools that help us find classical crypto usage automatically is going to be incredibly useful for our privacy and integrity research.

Nadia: It definitely sets a high bar for how we should be thinking about integrating these new cryptographic primitives into the software we build today.

Elias: And honestly, seeing this level of practical implementation in Python is really encouraging when you look at the current state of the PQC ecosystem evaluation they performed.

Priya: It’s a solid piece of work that bridges the gap between theoretical standardization and actual engineering deployment, which is what we need right now.

Nadia: We’ve got a lot to process on this paper, and it definitely makes me think about how we can apply these kinds of systematic evaluation methods to other areas.

Elias: Indeed, and I’m really looking forward to seeing how the community builds on this foundation for more robust PQC solutions.

Priya: Next time we sit down with a paper, I want us to focus on those real-world measurement implications that show what the data truly reveals about security.

cs.CR, quant-ph

Submitted: 2026-05-16

Updated: 2026-10-06

Comments: 11 pages, 3 figures, 10 tables. v2 corrects v1: decapsulation was timed on the implicit-rejection path; tables used the fastest of 3 runs and ignored --iterations; the GIL inference was unsupported. Benchmarks re-run (15 runs, raw data archived): handshake 231 us (v1: 243). CoV is now a stability metric. Code: quantum-safe-py 0.3.2, doi:10.5281/zenodo.23008259

Code: https://github.com/AnimeshShaw/quantum-safe

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 93/100

The gist: The production gap in post-quantum cryptography remains open despite NIST standardizing core algorithms, and this paper introduces a Python library designed to bridge that gap by providing hybrid key

Key concepts

Production Gap: This refers to the real-world difficulty in deploying post-quantum cryptography standards despite their finalization by NIST. It highlights missing tools like hybrid key exchange and migration paths needed for actual use, showing that algorithms are standardized but deployment infrastructure is lacking.
Hybrid by Default: The library adopts this principle, meaning it defaults to using both a classical and a post-quantum algorithm together for security. Users only need to explicitly choose classical-only if they specifically want that less secure option, making the secure path the easiest choice.
Coefficient of Variation (CoV): CoV is used as a practical test to measure timing stability in cryptographic operations. It compares the timing noise of a specific operation against a known stable reference, like AES-256-GCM. A low CoV suggests the operation is timing-stable and not vulnerable to subtle side-channel attacks.
Backend Agnostic Architecture: This design separates the core cryptographic algorithms from the user interface (API). This allows developers to easily swap out different underlying implementations, such as switching between liboqs or RustCrypto, without having to rewrite their main application code.

Terminology

Benchmark — 23× in this paper · explained in 2 episodes
Nadia — 19× in this paper · explained in 2 episodes
Elias — 18× in this paper · explained in 2 episodes
Coefficient of Variation — 7× in this paper
Core — 7× in this paper · explained in 2 episodes
Quantum-Safe Auditor — 6× in this paper
Abstraction — 4× in this paper · explained in 1 episode
Verification — 4× in this paper · explained in 2 episodes
Benchmarking — 2× in this paper · explained in 3 episodes
Global Interpreter Lock — 2× in this paper
Allocator — 1× in this paper · explained in 1 episode
Clustering — 1× in this paper · explained in 2 episodes
Cognitive Load — 1× in this paper · explained in 2 episodes
Concise Binary Object Representation — 1× in this paper
Formal Verification — 1× in this paper · explained in 2 episodes
Generalization — 1× in this paper · explained in 13 episodes
Geometric Distribution — 1× in this paper · explained in 2 episodes
Grounding — 1× in this paper · explained in 3 episodes
Modularity — 1× in this paper · explained in 9 episodes
Vulnerability Quantum-impact Estimation — 1× in this paper

Summary

The production gap in post-quantum cryptography remains open despite NIST standardizing core algorithms, and this paper introduces a Python library designed to bridge that gap by providing hybrid key exchange, versioned formats, and protocol helpers. The quantum-safe library closes these critical shortcomings by reducing the manual implementation of hybrid combiners from 45 lines of boilerplate code to just three lines, while also offering rigorous performance measurements and a systematic evaluation of the existing PQC ecosystem.

The Problem: The Production Gap

The algorithmic question regarding post-quantum cryptography has been settled with the finalization of FIPS 203, FIPS 204, and FIPS 205 standards for ML-KEM, ML-DSA, and SLH-DSA. However, the production gap remains open. This gap manifests in the lack of hybrid combiners, versioned key formats, protocol helpers, and migration tooling necessary for real-world deployment. The paper quantifies this deficiency by scoring nine PQC libraries across eight production-readiness dimensions using a ternary rubric (Full, Partial, or None), revealing that critical dimensions like Hybrid KEM support (11% Full) and Migration Path (22% Full) are severely underdeveloped in the current ecosystem.

The Solution: The quantum-safe Library

The core contribution is the Python library, quantum-safe, which addresses these gaps through five explicit design principles. First, it adheres to a Hybrid by default principle, where opting into classical-only mode requires an explicit flag to invert the burden of security. Second, it employs a Backend agnostic architecture that separates algorithm implementations from the API layer via an abstract backend, allowing users to switch between backends like liboqs or RustCrypto without modifying application code. Third, it is Protocol ready, shipping helpers for TLS configuration, X.509 hybrid certificate generation, and CBOR-serialised envelope formats. Fourth, it prioritizes a Migration first approach by using CBOR versioned key formats to support future upgrades and includes a scanner module to locate classical cryptography imports in source trees. Finally, it enforces Safe defaults, defaulting to ML-KEM-768 for KEM and Ed25519 + ML-DSA-65 for signatures.

Performance Benchmarks and Timing Analysis

The paper provides the first statistically rigorous per-operation overhead measurement for a Python hybrid PQC library, including a full X25519 + ML-KEM-768 handshake that completes in 243 µs under Docker/Linux. The performance analysis confirms that the overhead is negligible relative to typical network latency: 0.195 ms: 2.4% to 0.5% of the TLS budget. Furthermore, concurrent load tests demonstrate strong performance, showing throughput holds at 2,848 ops/s with only 4.9% degradation versus the single-user baseline, confirming that the Global Interpreter Lock (GIL) is released during C-level operations.

Timing Side-Channel Proxy: CoV

The paper introduces the Coefficient of Variation (CoV) as a practical timing side-channel proxy across all FIPS 203/204 operations. This methodology is used to assess timing stability against a constant-time noise floor, using AES-256-GCM (CoV = 2.1%) as the reference. The results show that ML-KEM-768 decapsulation achieves CoV = 3.9%, which is within the AES-256-GCM noise floor, suggesting timing stability, while ML-DSA-65 signing shows a high CoV of 51.5%, which is explicitly attributed to FIPS 204 rejection sampling rather than a side-channel vulnerability.

Ecosystem Evaluation and Toolchain

The paper systematically evaluated nine PQC libraries against eight production-readiness dimensions, highlighting critical gaps:

Hybrid KEM support (11% Full).
Migration path (22% Full).
Protocol integration (33% Full).

The quantum-safe library scores Full on all eight dimensions. It is designed to work alongside the Quantum-Safe Auditor (QSA) tool, which performs static analysis to detect classical cryptography usage in Python codebases, forming a complete migration toolchain. The open-source artefact, including 415 tests and the benchmark harness, is released under the Apache 2.0 licence.

Key Findings Summary

The full API reduces the hybrid KEM task from 45 lines of manual combiner code to three lines.

**"The first statistically rigorous per-operation latency measurement for a Python hybrid PQC library... Full handshake: 243 µs (Docker/Linux).

Improvements for AI systems

Here are the specific improvements and capabilities for AI systems derived from this research:

Improve Python-based security tooling by integrating a hybrid-by-default cryptographic layer into all new application development frameworks or libraries.
Develop automated, versioned key management systems that natively handle the serialization of hybrid key pairs (e.g., X25519 + ML-KEM) using CBOR format, ensuring interoperability across classical and PQC systems without manual boilerplate code.
Enhance static analysis tools (like the companion Quantum-Safe Auditor) to automatically detect and flag any usage of classical cryptography primitives within Python codebases, prioritizing migration paths based on urgency scores derived from the QSA tool.
Implement real-time timing side-channel detection for cryptographic operations in high-level libraries by monitoring the Coefficient of Variation (CoV). An AI system could dynamically flag any operation whose CoV exceeds a predefined threshold (e.g., 5% for PQC) as potentially vulnerable to timing attacks, providing a practical first-order screening tool where formal verification is not yet feasible.
Optimize concurrent cryptographic operations in Python environments by leveraging the empirical finding that the Global Interpreter Lock (GIL) is released during C-level PQC computations (like ML-KEM). AI systems managing high-throughput services can be tuned to utilize this, predicting and exploiting near-linear scaling of throughput up to 50x load increases without suffering severe performance degradation.
Create a Migration Infrastructure AI agent that automatically generates the necessary hybrid combiners, key derivation functions (HKDF), and protocol helpers required for transitioning existing classical deployments to quantum-safe standards, reducing manual development time from dozens of lines of boilerplate to three lines of library calls.
Build an AI-driven PQC performance predictor that uses the measured latency decomposition (e.g., 64 µs overhead for keygen) to accurately estimate the total handshake budget impact on a specific network topology (LAN vs WAN), allowing systems to preemptively adjust resource allocation based on expected latency profiles.

Abstract

FIPS 203, 204 and 205 closed the algorithmic gap in post-quantum cryptography (PQC); the production gap -- hybrid combiners, conformance evidence, migration tooling, stateful signing, protocol helpers -- remains open. A methodology that scores it must not choose its own dimensions, so we anchor nine to external requirements (CNSA 2.0, CMVP, the TNO CADI survey, the IETF hybrid draft). We present quantum-safe, a hybrid-by-default Python library built against this rubric, and an audit of nine PQC libraries (September 2026). The exercise can lower our own score, and it does. Hybrid combiners exist in three of six verifiable libraries, not the one a March-2026 snapshot found. Discovery and inventory tooling is the sharper gap: none of seven audited libraries has it; quantum-safe adds a CycloneDX CBOM. Only Bouncy Castle holds a CMVP FIPS 140-3 certificate; quantum-safe reports 225/225 runnable ACVP known-answer cases, which is conformance evidence, not validation. Bouncy Castle also supports LMS and XMSS where quantum-safe has LMS only, and quantum-safe's defaults sit below the CNSA 2.0 parameter sets; we score both against ourselves. Every benchmark figure is computed from archived raw runs (bootstrap intervals over 15 runs). A full X25519 + ML-KEM-768 handshake takes a median of 231 microseconds under Docker/Linux (95% interval 218-250), 5.3x an X25519-only handshake and 0.46-2.3% of a typical TLS 1.3 budget. Throughput is flat from 100 to 5,000 threads but below the single-thread rate: threads do not speed up the hybrid path, although liboqs does release the GIL in longer calls (ML-DSA-65 signing scales 2.6x on four threads). Timing side channels are treated in a companion paper.