← Back to Blog Tutorials

Open Quantum Safe: Origin, Governance, Roadmap

12 min read

When NIST kicked off its post-quantum cryptography standardization process in late 2016, one immediate question was: how do researchers and engineers actually try out the candidate algorithms? Reading academic papers is one thing. Building a working library that integrates a candidate KEM into a TLS stack and lets you measure performance, look for side channels, and write integration tests is another. The Open Quantum Safe project was founded that same year to fill this gap. Over the next decade, OQS became the central open-source ecosystem for post-quantum cryptography prototyping. Its flagship deliverables (liboqs and the OQS-OpenSSL/BoringSSL forks) became the reference points that nearly every PQC research paper cited and that nearly every PQC product implementation drew from. This post tells the story of OQS: where it came from, who runs it, what it has produced, and where it is going as the post-quantum migration moves from research into production.

Origins at the University of Waterloo

The Open Quantum Safe project was launched in early 2017 by Douglas Stebila and Michele Mosca, both at the University of Waterloo. Mosca had been one of the early voices warning about the quantum threat to public-key cryptography (his "1/2 chance by 2031" estimate is widely cited), and Stebila had been building post-quantum prototype implementations for several years. Together, they assembled a research group with funding from the Waterloo Institute for Quantum Computing and several Canadian government and industry partners.

The initial scope was modest. The plan was to package together implementations of the most promising PQC candidates into a single C library (liboqs) with a unified API, so that researchers could compare algorithms easily. The first release in February 2017 included nine algorithms: a few KEMs (LWE-based, code-based) and a few signature schemes. By the end of 2017, OQS had also released OQS-OpenSSL, a fork of OpenSSL that integrated liboqs and allowed PQC negotiation in TLS handshakes.

The library grew quickly as NIST's standardization process progressed. Round 1 of the NIST competition (2017) had 64 algorithm submissions; OQS integrated most of the leading candidates within months of submission. Round 2 (2019) and round 3 (2020) saw continuous integration of new candidate variants, optimization improvements, and security patches. By the time NIST announced the round-3 winners in July 2022 (Kyber, Dilithium, Falcon, SPHINCS+), OQS already had production-quality implementations of all of them.

The Linux Foundation Move

In late 2023, OQS announced that it was moving its governance from the Waterloo academic group to the Linux Foundation, specifically under the umbrella of the Post-Quantum Cryptography Alliance (PQCA). This was a significant institutional shift.

The reasoning was practical. As OQS deliverables became more widely deployed, the project needed institutional governance, security incident processes, sustainability funding, and trademark protection that an academic research group could not provide indefinitely. The Linux Foundation has structures for all of these. The PQCA specifically was set up as a vendor-neutral home for PQC tooling, with founding members including Amazon Web Services, IBM, Google, Microsoft, NVIDIA, Cisco, and several others.

Under PQCA governance, OQS retains its open-source identity and continues to be co-led by Stebila and a rotating cast of contributors from various institutions. The Linux Foundation provides infrastructure (legal entity, CI/CD, security disclosure processes), and the technical direction stays with the contributor community. This is a common and successful pattern for open-source projects that grow beyond a single research lab.

What OQS Has Produced

The OQS portfolio in 2026 includes several key deliverables:

liboqs: The core C library providing unified APIs for PQC KEMs and signatures. See liboqs Deep Dive for a developer-oriented walkthrough.
liboqs-python: Python bindings to liboqs, used heavily by researchers writing test scripts and prototypes.
liboqs-go: Go bindings.
liboqs-java: Java bindings.
liboqs-rust: Rust bindings (FFI-based; see also the rustcrypto-native ml-kem and ml-dsa crates).
OQS-OpenSSL Provider: A loadable provider for OpenSSL 3.x that adds PQC support without requiring a forked OpenSSL.
OQS-BoringSSL: A fork of BoringSSL for browser-side PQC experiments. Many of the early Chrome PQC TLS pilots were built on this fork.
OQS-Ant: Bindings into Apache Ant and other build systems.

Beyond the libraries, OQS publishes a continually updated reference document mapping algorithm parameter sets to their corresponding NIST identifiers, performance benchmarks, and security analysis summaries.

The Algorithms OQS Tracks

OQS's algorithm coverage has tracked the NIST standardization process closely. As of 2026, the OQS portfolio includes:

KEMs:

ML-KEM-512, ML-KEM-768, ML-KEM-1024 (FIPS 203 standardized).
Kyber round-3 variants (kept for backward compat).
HQC-128, HQC-192, HQC-256 (NIST round-4 finalist, code-based).
BIKE, FrodoKEM, NTRU, NTRU Prime, Saber (older candidates kept for research).
Classic McEliece (Kept due to its very long history).

Signatures:

ML-DSA-44, ML-DSA-65, ML-DSA-87 (FIPS 204 standardized).
Dilithium round-3 variants.
Falcon-512, Falcon-1024 / FN-DSA (FIPS 206 standardized).
SPHINCS+ / SLH-DSA in multiple parameter sets (FIPS 205 standardized).
Picnic (older candidate, removed from main library but available in archives).

This breadth makes OQS the natural starting point for any researcher who wants to compare PQC algorithms across categories. See What Is Post-Quantum Cryptography for a primer on the algorithm landscape.

Notable PQ TLS Demos

OQS has been instrumental in the public demonstrations of post-quantum TLS. The first major demo was a PQC-enabled connection between Chrome and Cloudflare in 2019, using the OQS-BoringSSL fork on the client side and a PQ-aware build of Cloudflare's TLS termination on the server side. The demo proved that PQC could work in a real TLS handshake at internet scale, even with the larger key and ciphertext sizes that PQC algorithms require.

Since then, OQS has been used in prototype deployments at Google, Cloudflare, Amazon Web Services, Microsoft, and several others. Each of these vendors eventually moved to either their own PQC implementations or upstream OpenSSL integration, but OQS provided the bootstrapping that made early experiments feasible.

The Cloudflare PQ-FIDO research (PQC for hardware security tokens) was prototyped using OQS. Various TLS 1.3 hybrid handshake research papers built on the OQS toolchain. The CECPQ2 experiment from Google in 2018, while not directly using OQS, was inspired by OQS's earlier CECPQ1 demonstrations.

Roadmap and Future Direction

Looking forward, OQS has several stated priorities:

Production-grade hardening: As organizations move PQC from experimentation to deployment, OQS is investing in better constant-time implementations, formal verification, and external security audits.
FIPS 140-3 path: OQS is working with vendors to provide FIPS-validatable implementations of standardized PQC algorithms.
Standardization tracking: As NIST releases additional standards (FIPS 206 for FN-DSA, future PQC TLS RFCs), OQS continues to provide reference implementations and integration test suites.
Embedded support: Better ARM/RISC-V support, smaller code footprint variants for IoT, and integration with embedded TLS stacks.
Hybrid construction support: First-class support for hybrid PQC + classical schemes, since those are what most production deployments will actually use. See Hybrid Encryption for the design rationale.

The PQCA umbrella also covers other PQC tooling beyond OQS, including pq-test-vector tools, post-quantum certificate authorities (the IETF LAMPS working group), and various integration testing frameworks. OQS is one node in this larger ecosystem.

How OQS Differs from Production Libraries

It is worth restating a point made in the liboqs Deep Dive: OQS is a research and prototyping platform, not a production cryptographic library suitable for high-assurance deployments. The OQS maintainers are explicit about this. The library prioritizes algorithm coverage and ease of experimentation over the kinds of hardening that production libraries (OpenSSL, wolfSSL, Botan, BoringSSL) invest in.

For production use, the recommended path is:

Use a production-hardened library (OpenSSL 3.5 or later for ML-KEM, ML-DSA and SLH-DSA, wolfSSL with PQC enabled, Botan with PQC enabled).
Use the rustcrypto crates if you are working in Rust (ml-kem, ml-dsa).
Use OQS for prototyping, testing, and research, but plan to migrate to a production library for deployment.

QNSQY takes the second route for its standardized algorithms: ML-KEM, ML-DSA and SLH-DSA come from RustCrypto's pure-Rust ml-kem, ml-dsa and slh-dsa crates. Its pre-standard FN-DSA and HQC come from the pqcrypto crates, which wrap the C implementations from the PQClean project.

Why OQS Matters for the PQC Migration

The post-quantum migration is going to take years. NIST has standardized the core algorithms (FIPS 203, 204, 205, 206), but the actual deployment into TLS stacks, certificate authorities, secure messaging protocols, and end-user products is just getting started. Throughout this migration, OQS will continue to be the place where researchers and engineers prototype the next steps. New algorithms (additional candidates, new parameter sets, hybrid constructions) will appear first in OQS. Bugs in new implementations will be caught and fixed in OQS before they propagate to production. Performance benchmarks will be published from OQS data.

For the practical work of getting PQC deployed, OQS is the foundation. The production libraries build on top of it. The browsers test against it. The standards bodies reference it. Without OQS, the PQC migration would have been significantly slower.

How QNSQY Relates to the OQS Ecosystem

QNSQY builds on the same standards rather than on liboqs. The ML-KEM, ML-DSA and SLH-DSA crates QNSQY uses pass NIST's ACVP test vectors for FIPS 203, 204 and 205, so at the algorithm level they compute the same results as other conforming implementations, including those in OQS. QNSQY's .qs files use QNSQY's own published format.

QNSQY combines ML-KEM with X25519 (x25519-dalek) using its own combiner, BLAKE3 in key-derivation mode over both shared secrets, and on paid plans can combine its post-quantum signatures with Ed25519 (ed25519-dalek). See Hybrid Encryption for the construction.

For the symmetric encryption layer, QNSQY uses AES-256-GCM (see AES-256-GCM Explained) and BLAKE3 for hashing (see BLAKE3 Hashing).

The OQS Approach to Algorithm Deprecation

A subtle but important part of OQS's contribution is the systematic approach to algorithm deprecation. As NIST's standardization process moved through rounds and various candidates dropped out, OQS had to decide what to do with implementations of those candidates. The pattern that emerged is to keep older candidates available for research and historical comparison, but to clearly label them as deprecated and to remove them from production-recommended configurations.

This matters because cryptographic ecosystems suffer when deprecated algorithms linger silently in production. The Heartbleed bug exploited a feature (heartbeat) that no one had used in years. Similar surprises lurk in any cryptographic library that does not actively prune dead code. OQS's explicit deprecation policy means that when a researcher cites "OQS supports algorithm X," there is a clear indication of whether X is current, deprecated, or removed.

For the FIPS-standardized algorithms specifically, OQS has been careful to align identifiers and parameter names with the FIPS documents. ML-KEM-768 in OQS produces output that matches the FIPS 203 reference implementation byte-for-byte. This level of precision is necessary for cross-implementation interoperability, and it is one of the things OQS has invested heavily in.

FAQ

Is OQS a NIST-endorsed implementation? No. NIST does not endorse specific implementations. NIST publishes algorithm specifications (FIPS 203, 204, 205, 206) and runs the CMVP validation program for FIPS-validated cryptographic modules. OQS is a community-driven project and is not on the FIPS-validated module list, though some downstream libraries that incorporate OQS-derived code may be FIPS-validated.

Can I use OQS in production? The OQS maintainers recommend against using liboqs directly in production. For production, use a hardened downstream library. OQS is the right tool for prototyping, testing, and research.

How does OQS handle the recent FIPS 203/204/205 standards? OQS has updated its ML-KEM, ML-DSA, and SLH-DSA implementations to match the final FIPS standards. The older Kyber, Dilithium, and SPHINCS+ identifiers remain in the library for backward compatibility but are clearly labeled as round-3 variants rather than the standardized algorithms.

What about Falcon / FN-DSA? NIST plans to standardize FN-DSA as FIPS 206, which it had not published as of October 2026. OQS includes the Falcon signature variants. How FN-DSA will differ from the Falcon submission will be settled when NIST publishes FIPS 206.

Does QNSQY directly link liboqs? No. QNSQY uses RustCrypto's pure-Rust crates for ML-KEM, ML-DSA and SLH-DSA, and the pqcrypto crates, Rust bindings to PQClean's C code, for its pre-standard FN-DSA and HQC. None of them links liboqs.

Sources

Open Quantum Safe project website. https://openquantumsafe.org
Stebila, D., and Mosca, M. "Post-quantum key exchange for the Internet and the Open Quantum Safe project." Selected Areas in Cryptography 2016. https://eprint.iacr.org/2016/1017
Linux Foundation PQCA announcement. "Linux Foundation Launches Post-Quantum Cryptography Alliance." February 2024. https://pqca.org
Open Quantum Safe project. liboqs source repository. https://github.com/open-quantum-safe/liboqs
Cloudflare. "Post-quantum TLS now supported in CloudFlare Tunnel." Cloudflare blog, July 2022. https://blog.cloudflare.com/post-quantum-tunnel/
NIST. "Post-Quantum Cryptography Standardization process." NIST CSRC project page. https://csrc.nist.gov/projects/post-quantum-cryptography

Protect Your Data Before Q-Day Arrives

QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.

Try QNSQY