Post-quantum cryptography libraries

Post-quantum cryptography libraries are software implementations of quantum-resistant algorithms such as ML-KEM, ML-DSA, and SLH-DSA that applications and protocols call instead of, or alongside, classical cryptography. This page is a maintained directory of notable libraries as of early 2026, grouped by role, with notes on which are production-grade and which are research code.

#How to read this directory

Most production deployments today use post-quantum algorithms for key exchange in hybrid mode, driven by the harvest now, decrypt later threat; post-quantum signatures see less deployment because certificate ecosystems move slowly (PKI migration to post-quantum). Production-grade below means the maintainers support the code for production use; research means the project itself advises caution. Licenses are summarized; check each project for exact terms.

#General-purpose libraries

Libraries applications link against for post-quantum primitives across many schemes.

liboqs offers the broadest algorithm coverage behind one API and is the standard research and prototyping choice, but its own guidance still favors production-supported implementations for deployment. Bouncy Castle is a long-established production library and the default route for Java and .NET. Botan and CIRCL are maintained production code from single vendors or maintainers; CIRCL powers parts of Cloudflare's edge. mlkem-native, from the Post-Quantum Cryptography Alliance's PQ Code Package project, takes the opposite approach to liboqs: one algorithm, production-grade, with machine-checked proofs for portions of the code, and it is consumed by liboqs itself.

#TLS stacks

TLS implementations with built-in post-quantum support, the main deployment vehicle for post-quantum TLS.

All of these are production code. OpenSSL 3.5 (April 2025, LTS) made hybrid key exchange a default for the largest installed base (openssl.org). BoringSSL backs Chrome and Google services and shipped hybrid post-quantum key exchange to browsers first (browser post-quantum adoption). AWS-LC is Amazon's BoringSSL-derived library with FIPS-validated lineage; s2n-tls builds on it and has carried hybrid post-quantum key exchange in AWS services for years, first with pre-standard candidates and now ML-KEM. wolfSSL targets embedded systems and adds the stateful hash-based signatures LMS and XMSS. Outside TLS, OpenSSH ships its own post-quantum key exchange (post-quantum SSH), and Mozilla's NSS provides the hybrid group used by Firefox.

#Reference implementations

Source collections meant for study, vendoring, and porting rather than linking as packaged libraries.

PQClean is the curated, continuously tested collection most downstream projects vendor. The team repositories preserve the original NIST Post-Quantum Cryptography Standardization submissions; note that the final FIPS standards differ in small but incompatible ways from the pre-standard Kyber and Dilithium versions.

#Language-specific

Go made post-quantum cryptography a standard library feature: Go 1.24 (February 2025) added the crypto/mlkem package and enabled the X25519MLKEM768 hybrid in crypto/tls by default, production-grade and maintained by the Go team. In Rust, rustls gets X25519MLKEM768 through its aws-lc-rs based provider, enabled by default in recent releases as of early 2026; the pure-Rust RustCrypto implementations are convenient but pre-1.0 and not independently audited. Java and .NET developers generally use Bouncy Castle, listed above.

#Choosing a library

For production TLS, prefer what your platform already ships: OpenSSL 3.5+, BoringSSL or AWS-LC, the Go standard library, or rustls. For production use of the raw primitives, Bouncy Castle, Botan, CIRCL, AWS-LC, and mlkem-native are maintained for that purpose. For research, benchmarking, or evaluating many algorithms behind one API, use liboqs; for auditable source to vendor into constrained or embedded systems, use PQClean. Whatever the choice, wrapping the library behind an internal interface preserves cryptographic agility for the algorithm changes still ahead. This directory is revised as libraries add algorithms; entries reflect the state as of early 2026.