up:: In the Protocols MOC
liboqs (Open Quantum Safe)
liboqs is an open-source C library, produced by the Open Quantum Safe (OQS) project, that implements post-quantum cryptographic algorithms behind one common interface, including the NIST standards ML-KEM, ML-DSA, and SLH-DSA, the Falcon signature slated to become FN-DSA, and research candidates such as HQC, BIKE, and Classic McEliece. It is the reference implementation most of the industry reaches for when prototyping and comparing PQC, and its own maintainers state that it should not be relied on in a production environment or to protect sensitive data.
The load-bearing fact for anyone planning a migration is the gap between a reference implementation and a certified one. liboqs is where the algorithms get exercised, integrated into test rigs, and compared, and that makes it enormously useful for learning the transition and standing up a proof of concept. It carries no FIPS 140-3 validation, so a regulated system cannot run liboqs as its production cryptographic module. The algorithm existing in liboqs and the algorithm being usable in a compliant deployment are two different things, and conflating them is the most common way a liboqs-based plan goes wrong.
The short version:
- liboqs is the C library at the center of the Open Quantum Safe project, now a Linux Foundation Post-Quantum Cryptography Alliance project, and it provides a single interface to the NIST PQC standards plus a wide set of research algorithms under an MIT license.
- Its companion oqs-provider plugs liboqs into OpenSSL 3.x through the provider interface, and language bindings expose it to Python, Go, Rust, Java, and C++.
- liboqs is built for research, prototyping, and benchmarking. The project states plainly that it should not be relied on in production or to protect sensitive data.
- It holds no FIPS 140-3 validation, so a regulated estate cannot use liboqs as its production cryptographic module.
- For validated production the path is a certified build such as AWS-LC, whose FIPS module carries ML-KEM. A vendor may base its module on the liboqs design, and the artifact that ships must be the certified one.
Think of liboqs as the master workshop where locksmiths prototype every new quantum-proof lock. Every design gets cut and tested there first, so it’s where the whole industry goes to see how a pattern works and to hold one against another. What leaves the bench is a working prototype, not a lock the building inspector has certified for a bank vault. When you need a lock that passes inspection, a manufacturer takes the proven design, builds it in a certified factory, and it’s that stamped, inspected lock that goes on the vault door.
What is liboqs?
liboqs is an open-source C library for quantum-safe cryptographic algorithms, described by its maintainers as a library for prototyping and experimenting with quantum-resistant cryptography. It is the core component of the Open Quantum Safe project, an open-source effort supporting the transition to quantum-resistant cryptography that became one of the launch projects of the Linux Foundation’s Post-Quantum Cryptography Alliance in February 2024. The project grew out of academic research by Douglas Stebila and Michele Mosca, whose paper introducing Open Quantum Safe appeared at Selected Areas in Cryptography 2016, and it is now maintained by a mix of academic and industry contributors. liboqs is licensed under the MIT license, with third-party components under BSD 3-Clause, Apache 2.0, public-domain CC0, and ISC terms.
Source: liboqs repository, github.com/open-quantum-safe/liboqs; Open Quantum Safe project site, openquantumsafe.org.
The purpose statement is the part that matters most for planning, and the project is unambiguous about it. Its documentation carries the notice, in capitals: “WE DO NOT CURRENTLY RECOMMEND RELYING ON THIS LIBRARY IN A PRODUCTION ENVIRONMENT OR TO PROTECT ANY SENSITIVE DATA.” The reason given is that the library is meant to help with research and prototyping, and that it has not received the level of auditing and analysis that reliance in a high-security setting would require. So liboqs is authoritative as a reference for how the algorithms behave, and it is deliberately scoped away from being the thing that guards live traffic.
Source: liboqs repository, github.com/open-quantum-safe/liboqs.
What algorithms does liboqs provide?
liboqs provides both the NIST-standardized algorithms and a broad set of research and alternate candidates, all behind one uniform C API, which is exactly what makes it convenient for prototyping and for comparing families against one another. The key-encapsulation mechanisms cover ML-KEM, HQC, BIKE, Classic McEliece, FrodoKEM, and NTRU-family schemes. The signature schemes cover ML-DSA, SLH-DSA, Falcon, the stateful hash-based schemes LMS and XMSS, and several additional-signature candidates such as CROSS, MAYO, SNOVA, and UOV.
| Algorithm | Family and role | Standardization status |
|---|---|---|
| ML-KEM (512, 768, 1024) | Lattice KEM, key exchange | NIST standard, FIPS 203 |
| HQC | Code-based KEM | Selected by NIST March 11, 2025, draft standard pending |
| BIKE | Code-based KEM | Research candidate |
| Classic McEliece | Code-based KEM | Selected for standardization, spec pending |
| FrodoKEM | Conservative lattice KEM | Research candidate |
| ML-DSA (44, 65, 87) | Lattice signature | NIST standard, FIPS 204 |
| SLH-DSA | Hash-based signature | NIST standard, FIPS 205 |
| Falcon | Lattice signature | Selected by NIST, FN-DSA (FIPS 206) in development |
| LMS, XMSS | Stateful hash-based signatures | NIST SP 800-208 |
Source (algorithm coverage): Open Quantum Safe supported algorithms, openquantumsafe.org; liboqs repository, github.com/open-quantum-safe/liboqs.
Source (standardization status): NIST, Post-Quantum Cryptography Standardization, csrc.nist.gov (Falcon published as FIPS 206 in development; HQC selected March 11, 2025).
For the same algorithm, liboqs ships portable reference C alongside hand-optimized assembly for common CPU families, which is one reason it is the usual substrate for cross-platform PQC experimentation. That coverage is a research convenience, and it carries a caution: the presence of an algorithm or a fast implementation in liboqs says nothing about whether that algorithm is available inside a validated cryptographic module.
Source: liboqs repository, github.com/open-quantum-safe/liboqs.
What is oqs-provider, and how does liboqs connect to OpenSSL?
oqs-provider is a single shared library that implements the OpenSSL provider interface and exposes liboqs algorithms, both KEMs and signatures, to applications through OpenSSL 3.x. It is what lets an OpenSSL-based application reach post-quantum key establishment, hybrid KEM groups, and signature operations through the standard OpenSSL EVP interface, and it is licensed under the MIT license.
Source: oqs-provider repository, github.com/open-quantum-safe/oqs-provider.
The relationship to OpenSSL is worth stating precisely, because the two clocks moved at different times. Before OpenSSL added native post-quantum algorithms in its 3.5 release, oqs-provider plugged into OpenSSL 3.x was the path to hybrid post-quantum TLS on that stack. It carried a separate, non-default dependency rather than getting PQC from the mainline library, which suited experimentation and proof-of-concept work. This is the same hybrid pattern the wider ecosystem adopted, where a classical key agreement runs alongside ML-KEM so the session stays confidential if either half holds. Documented banking proofs of concept have used exactly this shape, an Apache server with OpenSSL and the OQS provider negotiating a hybrid TLS 1.3 group, to test post-quantum handshakes without changing the application above.
Source: Balaji, H., et al., “Operationalising Post-Quantum TLS, Automated Configuration Profiling and Hybrid PQC Deployment in Financial Infrastructure,” arXiv, arXiv:2605.17955.
What language bindings does liboqs have?
liboqs is a C library, and the Open Quantum Safe project wraps it in bindings so other ecosystems can call the same algorithms without reimplementing them. The maintained bindings cover Python (liboqs-python), Go (liboqs-go), Rust (liboqs-rust), Java (liboqs-java), and C++ (liboqs-cpp). The project also publishes integration snapshots and demonstration material, including prototype integrations for OpenSSL and OpenSSH, so a team can stand up a working post-quantum TLS or SSH test without building the plumbing from scratch.
Source: Open Quantum Safe project site, openquantumsafe.org.
The bindings inherit the library’s scope. They make liboqs reachable from a Python service or a Go tool for prototyping and testing, and they carry the same production caution, because the underlying cryptographic engine is still the unvalidated liboqs.
Why is liboqs unsuitable for regulated production?
The reason is the difference between a reference implementation and a certified module. liboqs is written to demonstrate and compare the algorithms correctly, and the project has deliberately not put it through the auditing that high-security reliance would demand, which is why the maintainers advise against relying on it to protect sensitive data. On top of that scoping, liboqs holds no FIPS 140-3 validation. Federal systems, and any deployment bound by a FIPS requirement, are obligated to use a cryptographic module that carries a current CMVP validation, so an unvalidated library falls outside what those systems are permitted to run for cryptography, regardless of how correct the code is.
Source: liboqs repository, github.com/open-quantum-safe/liboqs; NIST, FIPS 140-3 and the Cryptographic Module Validation Program, csrc.nist.gov/projects/cryptographic-module-validation-program.
The distinction has a clean shape once separated into two columns.
| Property | liboqs (reference implementation) | Certified module (e.g. AWS-LC FIPS) |
|---|---|---|
| Primary purpose | Research, prototyping, comparison | Production cryptography |
| Security auditing | Best-effort, not high-security audited | Validated under the CMVP process |
| FIPS 140-3 validation | None | Holds a current CMVP certificate |
| Fit for regulated production | No, by the project’s own guidance | Yes, within the module’s validated boundary |
| Relationship | The design a vendor may prototype from | The artifact that actually ships |
Source: liboqs repository, github.com/open-quantum-safe/liboqs; AWS Security Blog, “AWS-LC FIPS 3.0, First cryptographic library to include ML-KEM in FIPS 140-3 validation,” aws.amazon.com.
What should regulated deployments use instead of liboqs?
A regulated deployment reaches for a cryptographic module that carries a current FIPS 140-3 validation covering the post-quantum algorithm it needs. AWS-LC is the worked example: by AWS’s account, its FIPS 3.0 module was the first open-source cryptographic module to include ML-KEM inside a completed FIPS 140-3 validation, so a system that must stay compliant can use ML-KEM there rather than through liboqs. The OpenSSL project, similarly, submitted a 3.5-series module for FIPS 140-3 validation in October 2025 with the certificate still pending, which is the compliant post-quantum path for OpenSSL-bound systems once it lands.
Source: AWS Security Blog, “AWS-LC FIPS 3.0, First cryptographic library to include ML-KEM in FIPS 140-3 validation,” aws.amazon.com; OpenSSL 3.5.4 FIPS 140-3 submission announcement, openssl-library.org.
The mental model is that the algorithm design and the shipping module are separate things. A vendor may prototype against liboqs, and even derive its implementation from the same reference, and what goes into a regulated production system is the vendor’s CMVP-validated module. So the right way to read “our HSM supports ML-KEM” is to ask which validated module carries it, not whether the algorithm exists in liboqs.
Common misconceptions
- “liboqs is production-ready post-quantum crypto.” The project states in capitals that it does not recommend relying on the library in production or to protect sensitive data. It is built for research and prototyping, and it has not had the auditing that production reliance would require.
- “If ML-KEM is in liboqs, my FIPS systems can use it.” liboqs holds no FIPS 140-3 validation. A FIPS-bound system has to use a CMVP-validated module, so it reaches ML-KEM through a certified build such as AWS-LC, not through liboqs.
- “liboqs and oqs-provider are the same thing.” liboqs is the C algorithm library. oqs-provider is a separate shared library that exposes liboqs through the OpenSSL 3.x provider interface, so an OpenSSL application can call the algorithms.
- “You need liboqs to do post-quantum TLS in OpenSSL now.” OpenSSL 3.5 added native ML-KEM and hybrid TLS groups, so the mainline library reaches PQC on its own. oqs-provider remains the route for earlier OpenSSL branches that lack native support.
- “A vendor building on liboqs means the vendor’s product is validated.” Basing an implementation on the liboqs design says nothing about validation. Only a current CMVP certificate for the vendor’s own module establishes that.
- “liboqs only ships the NIST winners.” It also carries research and alternate candidates such as BIKE, FrodoKEM, Classic McEliece, and several additional-signature schemes, retained so researchers can compare families and test alternatives.
Questions people ask
Is liboqs safe to use in production? The Open Quantum Safe project advises against it. Its documentation states that it does not recommend relying on the library in a production environment or to protect sensitive data, because the library is scoped for research and prototyping and has not been audited to a high-security bar.
Is liboqs FIPS 140-3 validated? No. liboqs carries no CMVP validation. Regulated deployments that must use a validated cryptographic module cannot use liboqs for production cryptography and instead use a certified build such as AWS-LC.
What is the difference between liboqs and oqs-provider? liboqs is the underlying C library that implements the algorithms. oqs-provider is a companion shared library that exposes those algorithms to OpenSSL 3.x applications through the provider interface, so it is the bridge between liboqs and the OpenSSL EVP API.
Which algorithms does liboqs support? It supports the NIST standards ML-KEM, ML-DSA, and SLH-DSA, the Falcon signature slated to become FN-DSA, and a wide set of research and alternate candidates including HQC, BIKE, Classic McEliece, FrodoKEM, and additional-signature schemes such as CROSS, MAYO, SNOVA, and UOV.
What license is liboqs under? The MIT license, with some third-party components under BSD 3-Clause, Apache 2.0, public-domain CC0, and ISC terms. That permissive licensing is part of why it became the common substrate for PQC experimentation.
Can I call liboqs from Python, Go, Rust, or Java? Yes. The project maintains bindings for Python, Go, Rust, Java, and C++, each wrapping the same C library, and it publishes demonstration integrations for OpenSSL and OpenSSH. The bindings inherit the library’s research-and-prototyping scope.
If my HSM vendor says it supports ML-KEM, is that liboqs? Not necessarily, and it does not matter for compliance. The vendor may have prototyped against liboqs, and the production artifact must be the vendor’s own CMVP-validated module. Ask which validated module carries the algorithm rather than whether it exists in liboqs.
Should my team use liboqs at all, then? For learning the algorithms, building a proof of concept, or comparing options, liboqs is well suited and widely used. For anything that guards live or regulated traffic, the deployment moves to a validated module, with liboqs staying on the prototyping bench.
Everything here is the map, given freely. When your team needs its cryptographic libraries inventoried, its liboqs and oqs-provider proofs of concept separated cleanly from what a regulated deployment is allowed to run, and its production path sequenced onto validated modules, that’s what an alignment briefing is for.
Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.