Python PQC Libraries Compared

Python developers building post-quantum cryptography into their applications in 2026 face a landscape with several competing libraries at different maturity levels. This comparison covers the four primary options: the pqcrypto package from Backbone, liboqs-python from Open Quantum Safe, pyca/cryptography (the most-downloaded Python crypto library), and PyCryptodome. For each, we evaluate algorithm coverage, production readiness, maintenance status, and the appropriate use case.

For the cross-language and production-library decision, start with the broader post-quantum cryptography library comparison.

Quick comparison table

Feature	pyca/cryptography	liboqs-python (oqs)	pqcrypto (Backbone)	PyCryptodome
ML-KEM support	Yes (v48+)	Yes	Yes	No
ML-DSA support	Yes (v48+)	Yes	Yes	No
SLH-DSA support	No	Yes	No	No
Production-ready	Yes	No (research)	No (research)	N/A (no PQC)
FIPS compliance path	Yes	No	No	No
Hybrid mode helpers	No	No	No	No
PyPI downloads/month	~250M	~50K	~15K	~60M
Python version	3.9+	3.8+	3.9+	3.6+
Backend	Rust (native)	C (liboqs FFI)	C (PQClean FFI)	C extension
License	Apache 2.0 / BSD	MIT	MIT	BSD
Funding	Sovereign Tech Agency	NLnet, various	Backbone Labs	Community

pyca/cryptography (version 48+)

Status: Production-ready

In June 2026, Trail of Bits shipped ML-KEM and ML-DSA support in pyca/cryptography version 48, funded by the Sovereign Tech Agency. This is the single most important event in Python PQC history because pyca/cryptography is the eleventh most-downloaded package on PyPI, serving as the cryptographic foundation for requests, paramiko, urllib3, and hundreds of other critical packages.

What is included

• ML-KEM (FIPS 203): Key encapsulation with ML-KEM-512, ML-KEM-768, and ML-KEM-1024
• ML-DSA (FIPS 204): Digital signatures with ML-DSA-44, ML-DSA-65, and ML-DSA-87
• Implementation uses Rust bindings to AWS LibCrypto (aws-lc-rs), which is FIPS-validated

What is not included

• SLH-DSA (FIPS 205) is not yet available
• No composite/hybrid key helpers (you combine algorithms yourself)
• No direct TLS integration (that happens at the OpenSSL/transport layer)

Code example

from cryptography.hazmat.primitives.asymmetric import ml_kem, ml_dsa

# ML-KEM key encapsulation
private_key = ml_kem.generate_private_key(ml_kem.MLKEM768)
public_key = private_key.public_key()
shared_secret, ciphertext = public_key.encapsulate()
decapsulated_secret = private_key.decapsulate(ciphertext)
assert shared_secret == decapsulated_secret

# ML-DSA signing
signing_key = ml_dsa.generate_private_key(ml_dsa.MLDSA65)
signature = signing_key.sign(b"message to sign")
signing_key.public_key().verify(signature, b"message to sign")

When to use

Use pyca/cryptography when you need production-grade PQC in a Python application. It is the correct default choice for any project that already depends on pyca/cryptography (which is most Python web applications). The implementation is backed by a FIPS-validated cryptographic module and maintained by a well-funded team with a strong security track record.

liboqs-python (oqs-python)

Status: Experimental / Research

The Open Quantum Safe project maintains Python bindings to liboqs, their C library implementing a wide range of post-quantum algorithms. The Python package provides access to every algorithm that liboqs supports, including algorithms that have not yet been standardized.

What is included

• All NIST-standardized algorithms: ML-KEM, ML-DSA, SLH-DSA (all parameter sets)
• Additional algorithms: FrodoKEM, Classic McEliece, BIKE, HQC, Falcon (when standardized)
• Signature and KEM generic APIs: Unified interface across all algorithms

What is not included

• No FIPS validation
• No constant-time guarantees on the Python binding layer
• Platform support varies (published Docker images are linux/amd64 only; Apple Silicon requires building from source or running under QEMU emulation)

Code example

import oqs

# KEM
kem = oqs.KeyEncapsulation("ML-KEM-768")
public_key = kem.generate_keypair()
ciphertext, shared_secret_enc = kem.encap_secret(public_key)
shared_secret_dec = kem.decap_secret(ciphertext)

# Signature
sig = oqs.Signature("ML-DSA-65")
public_key = sig.generate_keypair()
signature = sig.sign(b"message")
is_valid = sig.verify(b"message", signature, public_key)

When to use

Use liboqs-python for research, prototyping, interoperability testing, and evaluating algorithms that pyca/cryptography does not yet support (SLH-DSA, HQC, Classic McEliece). Do not use it in production systems that handle real user data, as the library explicitly states it is for prototyping and evaluation.

pqcrypto (Backbone)

Status: Experimental / Research

The pqcrypto package from Backbone Labs provides Python bindings built on PQClean reference implementations via CFFI. It focuses on clean, documented APIs and targets developers who want to experiment with PQC without dealing with native library compilation.

What is included

• ML-KEM: ML-KEM-512, ML-KEM-768, ML-KEM-1024
• ML-DSA: ML-DSA-44, ML-DSA-65, ML-DSA-87
• Pre-compiled wheels for common platforms (v0.4.0 added Python 3.14 support, January 2026)

What is not included

• No FIPS validation
• No SLH-DSA support
• No security audits
• Smaller team and contributor base compared to OQS or pyca

Code example

from pqcrypto.kem.ml_kem_768 import generate_keypair, encrypt, decrypt

public_key, secret_key = generate_keypair()
ciphertext, shared_secret = encrypt(public_key)
decrypted_secret = decrypt(secret_key, ciphertext)

When to use

Use pqcrypto when you need a lightweight research tool with minimal dependencies and do not want to compile liboqs from source. It is appropriate for educational projects, proof-of-concept implementations, and performance benchmarking. Do not use it for production systems.

PyCryptodome

Status: No PQC support

PyCryptodome is a popular self-contained Python cryptography library that serves as a drop-in replacement for PyCrypto. As of August 2026, PyCryptodome does not include any post-quantum algorithms. Its maintainer has not announced a PQC roadmap.

What it provides

• Classical algorithms: RSA, ECC, AES, ChaCha20, SHA-3, and more
• Self-contained with no external dependencies
• Well-tested and widely used

What it lacks

• No ML-KEM, ML-DSA, or SLH-DSA
• No announced timeline for PQC additions

When it is relevant

PyCryptodome remains the right choice for classical cryptography in contexts where you need a self-contained library without Rust or C compilation toolchain dependencies. For PQC specifically, it offers nothing today.

Production readiness assessment

The term “production-ready” in cryptography means several things simultaneously:

1. Implementation correctness: Passes known-answer tests (KATs) and interoperability tests
2. Side-channel resistance: Constant-time operations that do not leak secrets through timing
3. Maintenance commitment: Active security response team, funded development
4. Audit history: Third-party security review of the implementation
5. FIPS validation: Formal NIST validation for regulated environments

Here is how each library scores:

Criterion	pyca/cryptography	liboqs-python	pqcrypto	PyCryptodome
KAT testing	Yes	Yes	Yes	N/A
Constant-time backend	Yes (aws-lc-rs)	Partial (liboqs C)	No guarantees	N/A
Funded maintenance	Yes	Yes (grants)	Limited	Community
Security audit	Yes (Trail of Bits)	Yes (liboqs C core)	No	Yes (classical)
FIPS pathway	Yes	No	No	No

The clear conclusion: pyca/cryptography is the only production-ready option for Python PQC today.

Migration path from classical to PQC

For teams currently using pyca/cryptography for classical operations:

# Before: Classical ECDH key exchange
from cryptography.hazmat.primitives.asymmetric import ec
private_key = ec.generate_private_key(ec.SECP256R1())

# After: PQC key encapsulation (not a drop-in replacement)
from cryptography.hazmat.primitives.asymmetric import ml_kem
private_key = ml_kem.generate_private_key(ml_kem.MLKEM768)

Note that KEM (Key Encapsulation Mechanism) is not architecturally identical to Diffie-Hellman key exchange. In DH, both parties contribute key material. In KEM, one party generates a shared secret and encapsulates it for the other. This means application protocols that assume DH-style exchange need structural changes, not just algorithm swaps.

For teams using liboqs-python in research that want to move to production:

1. Replace import oqs with from cryptography.hazmat.primitives.asymmetric import ml_kem, ml_dsa
2. Update API calls (the interfaces differ)
3. Remove any SLH-DSA usage until pyca/cryptography adds support
4. Add proper error handling for decapsulation/verification failures

Performance considerations

PQC operations are generally fast on modern hardware. Here are approximate performance characteristics on a typical server (AMD EPYC, single core):

Operation	pyca/cryptography	liboqs-python	pqcrypto
ML-KEM-768 keygen	~30 us	~35 us	~40 us
ML-KEM-768 encaps	~35 us	~40 us	~45 us
ML-KEM-768 decaps	~35 us	~40 us	~45 us
ML-DSA-65 keygen	~80 us	~90 us	~100 us
ML-DSA-65 sign	~250 us	~280 us	~300 us
ML-DSA-65 verify	~90 us	~100 us	~110 us

The performance differences between libraries come from backend optimization. pyca/cryptography uses aws-lc-rs which includes platform-specific assembly optimizations. liboqs uses optimized C but with Python FFI overhead. pqcrypto uses PQClean reference implementations which prioritize correctness over speed.

For most applications, all three libraries are fast enough that PQC performance is not the bottleneck. Network latency and larger key/ciphertext sizes matter more than raw computation speed.

Dependency and supply chain considerations

Factor	pyca/cryptography	liboqs-python	pqcrypto
Native compilation required	Yes (Rust)	Yes (C)	Yes (C)
Pre-built wheels	Yes (all major platforms)	Limited	Most platforms
Transitive dependencies	manylinux, cffi	liboqs system lib or bundled	cffi
Supply chain attacks surface	Small (well-monitored)	Medium	Medium
Reproducible builds	Yes	Partial	Partial

FAQ

Q: Which Python library should I use for production PQC?

pyca/cryptography version 48 or later. It is the only option with a FIPS-validated backend, active security maintenance, and a proven track record.

Q: Can I use liboqs-python in production?

The Open Quantum Safe project explicitly states that liboqs is for prototyping and evaluation. You should not use it in production systems that handle sensitive data. Use it for research, testing, and evaluating algorithms not yet available elsewhere.

Q: Does PyCryptodome support post-quantum algorithms?

No. As of August 2026, PyCryptodome has no PQC support and no announced roadmap for adding it.

Q: What about the qcrypto package on PyPI?

The qcrypto package is a lightweight wrapper around liboqs-python that provides simpler APIs. It is not independently maintained or audited. Use liboqs-python directly if you need OQS functionality.

Q: Can I combine pyca/cryptography PQC with classical algorithms for hybrid mode?

Yes, but you need to implement the hybrid logic yourself. There is no built-in “hybrid KEM” function. Concatenate or KDF-combine the shared secrets from a classical ECDH exchange and an ML-KEM encapsulation. Several RFCs define how to do this correctly in TLS contexts.

Q: How do I install pyca/cryptography with PQC support?

PQC support is included by default in version 48 and later. Simply run pip install cryptography>=48.0 and the ML-KEM and ML-DSA modules are available. No feature flags or optional dependencies are needed.

Q: Is SLH-DSA available in any Python library?

Yes, through liboqs-python. It is the only Python library that currently provides SLH-DSA (FIPS 205). pyca/cryptography has not yet added SLH-DSA support.

Q: What Python version do I need?

pyca/cryptography 48 requires Python 3.9 or later. liboqs-python works with Python 3.8+. pqcrypto version 0.4.0 supports up to Python 3.14.

Recommendation summary

• Production applications: Use pyca/cryptography (v48+). Full stop.
• Research and algorithm evaluation: Use liboqs-python for the widest algorithm coverage.
• Quick prototyping with minimal setup: Use pqcrypto from Backbone Labs.
• Classical-only needs: PyCryptodome remains fine but offers no PQC path forward.

The Python PQC ecosystem matured significantly with the June 2026 release of pyca/cryptography v48. For the first time, production-grade post-quantum cryptography is available through the same library that most Python developers already depend on for TLS, certificate handling, and symmetric encryption.

Sources

• Trail of Bits: Shipping post-quantum cryptography to Python — Official announcement of ML-KEM and ML-DSA in pyca/cryptography v48, funded by Sovereign Tech Agency
• pyca/cryptography v48.0.0 Changelog — Release notes confirming PQC algorithm availability
• PyPI: cryptography 48.0.0 — Package distribution, Python 3.9+ requirement
• Open Quantum Safe: liboqs-python — Python bindings to liboqs (MIT license, experimental/research use only)
• NIST FIPS 203: ML-KEM Standard — ML-KEM specification implemented by pyca/cryptography
• NIST FIPS 204: ML-DSA Standard — ML-DSA specification implemented by pyca/cryptography
• AWS Security Blog: AWS-LC FIPS 3.0 — aws-lc-rs backend used by pyca/cryptography for FIPS-validated PQC