Open-Source Post-Quantum Libraries: liboqs, OpenSSL, BoringSSL, Go and Java Maturity
Two very different kinds of library
Post-quantum code comes in two flavors. The first is mainstream TLS libraries that added the NIST-standardized algorithms (ML-KEM, ML-DSA, SLH-DSA) and ship them to millions of users. The second is research and prototyping toolkits such as the Open Quantum Safe project. Mixing them up is the most common mistake builders make.
Open Quantum Safe: liboqs and oqs-provider
liboqs is an open source C library of quantum-safe algorithms under the MIT license, with a common API and test and benchmark tools. Its README states in capital letters that the maintainers do not currently recommend relying on it in a production environment or to protect sensitive data, because it is volunteer-maintained, not commercially supported, and lacks the auditing needed for high-security use. It also recommends hybrid cryptography for early deployments. The README lists ML-KEM, HQC, FrodoKEM, Classic McEliece and others for key exchange; ML-DSA, SLH-DSA, Falcon, MAYO, UOV and others for signatures; and LMS and XMSS as stateful signatures. It assigns support tiers: ML-KEM is Tier 1 (Core), ML-DSA and the stateful schemes are Tier 2, and many others are Tier 3 (Community).
oqs-provider plugs liboqs into OpenSSL 3 as a provider, which makes it handy for trying exotic algorithms in a lab. Its README carries the same production warning. It also says that on OpenSSL 3.5 and later, algorithms OpenSSL already implements natively (pure ML-KEM, ML-DSA, SLH-DSA and hybrids such as X25519MLKEM768) are disabled in the provider at runtime, and that using the standardized families through the provider is discouraged on any OpenSSL version because of differences in key representation. Enabling too many algorithms can also crash older OpenSSL builds.
Maturity table
This table mixes vendor claims with my reading of the sources. It describes key agreement and signatures separately because signatures lag.
| Library | Key agreement | Signatures | My honest label |
|---|---|---|---|
| OpenSSL 3.5 and later | Hybrid on by default (X25519MLKEM768) | ML-DSA and SLH-DSA added in 3.5.0 | Mainstream for key agreement; signatures new, test in your own PKI |
| BoringSSL | Supported | ML-DSA-44/65/87 listed by Cloudflare | Used by Chromium; API is not stable, so track upstream |
| AWS-LC | X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024 | Supported | Mainstream; Rust users reach it through aws-lc-rs |
| Go | Default from Go 1.24 | Internal in 1.26; public crypto/mldsa proposed for 1.27 | Key agreement mainstream; signatures not yet public API |
| Java (OpenJDK) | Default from JDK 27 (JEP 527) | ML-DSA APIs since 24, not yet in javax.net.ssl TLS | Key agreement arriving; plan on provider code for now |
| rustls | Default since 0.23.27 | Unstable, behind a feature flag | Key agreement mainstream |
| Node.js | Default in 24.5.0 and 22.20.0 | ML-DSA in 24.5.0 and later | Inherits OpenSSL 3.5 |
| liboqs and oqs-provider | Many algorithms | Many algorithms | Research and interoperability testing only |
The Go, Java, Node and rustls entries come from Cloudflare's support table, which itself says listings are for reference only and that maintainers are responsible for their own software.
How to choose
- Use the platform you already ship. Upgrade the TLS library and runtime rather than adding a new dependency. This gives you hybrid key agreement with almost no code.
- Use liboqs in a lab. Good for benchmarking sizes, trying a candidate like Falcon before its standard is final, or interoperability tests. Do not protect real secrets with it.
- Prefer standardized names. The liboqs README says the ML-KEM, ML-DSA and SLH-DSA names are stable. Pre-standard names like Kyber and Dilithium variants should not appear in production configs.
- Pin and monitor. Pin library versions, subscribe to security advisories, and keep a test that prints the negotiated group on every deploy.
What is still experimental
Post-quantum signatures in TLS and X.509 are the least settled area. Cloudflare's 2025 post estimated that post-quantum certificates would be unlikely to be broadly trusted or available before 2027, and that swapping to ML-DSA-44 would add about 15 kB to a handshake. It also warned against deploying MAYO or SNOVA now. Falcon (FN-DSA) saves bytes but is described as dangerous to implement when signing on the fly. See the signature comparison and NIST standards status.
Finally, remember that no library fixes a protocol that exposes public keys carelessly; see exposed public keys for the blockchain version of that lesson.
Sources and further reading
- liboqs README (Open Quantum Safe)
- oqs-provider README (OpenSSL 3 provider)
- Cloudflare docs: post-quantum support by browser, library and server
- OpenSSL 3.5 series release notes
- Go 1.24 release notes (crypto/mlkem, X25519MLKEM768)
- OpenJDK JEP 527: post-quantum hybrid key exchange for TLS 1.3
- Cloudflare blog: state of the post-quantum Internet in 2025
Reported as of 2026-10-09. Library versions, defaults and standards status change often, so check the primary documents and test on your own stack before relying on anything here. Nothing here is financial advice or a security audit. The QNT memecoin is independent of Quantinuum Ltd, the real company, and of every project, library, lab and chain named on this page.
Frequently asked questions
Is liboqs safe to use in production?
Its own README says it does not recommend relying on it in production or to protect sensitive data. Use it for research, prototypes and interoperability tests.
What should I use for production post-quantum key exchange?
The support built into current mainstream libraries, such as OpenSSL 3.5 and later, BoringSSL, AWS-LC, Go 1.24 and later, or rustls, in hybrid mode.
Can I use oqs-provider with OpenSSL 3.5?
It works, but its README says native algorithms such as ML-KEM and ML-DSA are disabled in the provider on 3.5 and later, so it mainly adds the other candidates.
Are post-quantum signatures ready for TLS certificates?
Not broadly. Library support is arriving, but public web PKI support was reported as unlikely before 2027.
Keep reading
- Try Post-Quantum TLS Today: OpenSSL 3.5, Browsers and Cloudflare Test Pages
A hands-on developer guide to hybrid ML-KEM key exchange in TLS: which OpenSSL, browser, Go and Java versions support it, and how to check a connection. - ML-KEM Explained: The Post-Quantum Key Exchange Standard
ML-KEM (FIPS 203) is NIST's standard for post-quantum key encapsulation. Learn what a KEM is, how lattices fit in, and where it is used, in plain English. - ML-DSA Explained: The Post-Quantum Signature Standard
ML-DSA (FIPS 204) is NIST's main post-quantum digital signature standard. Learn how lattice signatures work, how they compare to ECDSA, and the trade-offs. - Crypto Agility Explained: Preparing for Algorithm Change
Crypto agility is the ability to swap cryptographic algorithms without rebuilding a system. Learn why it matters for the post-quantum shift and for blockchains. - NIST Post-Quantum Standards Status: FIPS 203, 204, 205, FN-DSA and HQC
Which post-quantum standards are final, which are still drafts, and what that means for companies deciding what to deploy in late 2026.
All Quantum computing guides | Back to top | Search the site
Main pages: Quantum computing explained | Quantum and crypto | Companies | Quantum news | Glossary