liboqs

The Open Quantum Safe project’s C library of post-quantum key encapsulation and signature algorithms behind one API, from the NIST standards to candidates still under review, built for prototyping and research.

PQCA project

What it is: Post-quantum cryptography
Type: Open source
Made by: Open Quantum Safe, a Series of LF Projects (Post-Quantum Cryptography Alliance)
Foundation: Post-Quantum Cryptography Alliance, joined February 2024. Part of the Open Quantum Safe project. Part of the Linux Foundation
License: MIT (some bundled algorithm implementations carry other open licences)
Facts checked: 28 October 2026

What it is

liboqs collects implementations of post-quantum algorithms and puts them behind a common C API, so the same few calls work whichever algorithm you name: OQS_KEM_new("ML-KEM-768"), then keypair, encapsulate and decapsulate, or OQS_SIG_new with sign and verify. Version 0.16.0, released on 9 July 2026, covers the three NIST standards (ML-KEM, ML-DSA and SLH-DSA), HQC and Falcon, which NIST has picked but not yet published, older or rejected KEMs such as Classic McEliece, FrodoKEM, BIKE and NTRU, the candidates in NIST’s additional signature round such as MAYO, CROSS, UOV and SNOVA, and the stateful hash-based signatures LMS and XMSS. Each family has a support tier: ML-KEM is Tier 1 (core), ML-DSA, HQC, FrodoKEM, LMS and XMSS are Tier 2, and the rest are community-maintained. Much of the code comes from upstream projects; the default ML-KEM and ML-DSA are now the formally verified mlkem-native and mldsa-native from the PQCA’s sister project, the PQ Code Package.

The library also ships a test harness and benchmarks, and is the base of the rest of Open Quantum Safe: oqs-provider plugs it into OpenSSL 3 for post-quantum and hybrid TLS 1.3, X.509 certificates and CMS; demos run it in nginx, curl, Chromium, HAProxy and Wireshark; and wrappers expose it to C++, Go, Java, Python and Rust. Researchers use it to compare candidate algorithms, and vendors including Mullvad, ExpressVPN, strongSwan, Entrust and Utimaco have built prototypes or betas on it. Its own README is blunt about the limits: it does not recommend relying on liboqs in production or to protect sensitive data, because the code has not had the auditing high-security use needs.

Why teams pick it

One API for dozens of algorithms, so you can swap ML-KEM for HQC or ML-DSA for MAYO with a string and compare sizes and speed
Tracks NIST closely: standardised algorithm names stay stable, while pre-standard versions such as Dilithium and SPHINCS+ were deprecated and then removed on a published schedule
Its ML-KEM and ML-DSA defaults come from mlkem-native and mldsa-native, whose x86_64 and AArch64 assembly is proved correct and constant-time
A whole ecosystem around it: oqs-provider for OpenSSL 3, language wrappers and ready-made demos for TLS and SSH

Watch out for

Its maintainers advise against production use or protecting sensitive data, and it is not FIPS 140 validated; for production pick AWS-LC, BoringSSL, OpenSSL 3.5+ or a platform library
Algorithms outside the NIST standards may be renamed, changed or dropped between releases, and many are community-maintained with best-effort support
Only primitives: no TLS, certificate handling or key management of its own; the protocol integrations are separate prototypes such as oqs-provider
Not commercially supported; it is run by academic, part-time and volunteer contributors, and releases come a few times a year

Alternatives

What all post-quantum cryptography have in common →Compare side by side →

mlkem-nativeOpen sourceA portable C90 implementation of ML-KEM (FIPS 203) with formally verified C and assembly, meant to be copied into other cryptographic libraries; AWS-LC, liboqs and, through AWS-LC, rustls use it.

How it fits with other technologies

What liboqs uses

Key encapsulation with ML-KEM-768 through the generic API · c

#include <oqs/oqs.h>

OQS_KEM *kem = OQS_KEM_new(OQS_KEM_alg_ml_kem_768);   /* "ML-KEM-768" */
uint8_t *pk = malloc(kem->length_public_key);         /* 1184 bytes */
uint8_t *sk = malloc(kem->length_secret_key);
uint8_t *ct = malloc(kem->length_ciphertext);         /* 1088 bytes */
uint8_t ss_alice[32], ss_bob[32];

OQS_KEM_keypair(kem, pk, sk);              /* Alice publishes pk */
OQS_KEM_encaps(kem, ct, ss_bob, pk);       /* Bob: a fresh secret, sealed to pk */
OQS_KEM_decaps(kem, ss_alice, ct, sk);     /* Alice opens ct: ss_alice == ss_bob */

OQS_MEM_secure_free(sk, kem->length_secret_key);
OQS_KEM_free(kem);

See it in a real stack

No architecture uses liboqs yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2014–2026

Open Quantum Safe was founded in 2014 at the University of Waterloo by Michele Mosca and Douglas Stebila, as a research project to prototype and evaluate quantum-resistant cryptography. The liboqs repository opened in August 2016, the year NIST launched its post-quantum competition, together with a fork of OpenSSL 1.1.1 that used it for TLS. Over the competition’s rounds liboqs became a common test bench, adding candidates as they were submitted and dropping them as they were eliminated, with contributors from universities and companies such as Cisco, IBM Research and Microsoft Research.

On 6 February 2024 the Linux Foundation launched the Post-Quantum Cryptography Alliance with OQS as a founding project, giving it what the announcement called a permanent home. Its OpenSSL fork has since been retired in favour of oqs-provider for OpenSSL 3, because OpenSSL 1.1.1 reached end of life. Once NIST’s standards were final, liboqs moved to them: ML-DSA was updated to the final FIPS 204 in version 0.12.0 in December 2024, the pre-standard Dilithium was removed in November 2025 and SPHINCS+ in July 2026, while Kyber stays only as a community-maintained extra. From 0.13.0 in April 2025 the default ML-KEM became mlkem-native, and from 0.16.0 the default ML-DSA became mldsa-native, both from the PQ Code Package, so liboqs relies on formally verified code for the standards while keeping room for research algorithms.

Why it’s built this way

Don’t pick winners: OQS follows the NIST process rather than its own judgement of which algorithms are safe, so liboqs carries many candidates and recommends applications use the standards that come out of it.
One API for every algorithm: Researchers and integrators wanted to plug candidates into protocols and compare them without rewriting code for each, so all KEMs and all signatures share the same calls and size fields.
Recommend hybrids: The algorithms are new and some candidates have been broken, so OQS advises pairing them with RSA or elliptic curves so a deployment is at least as secure as before.
Prototype, not product: Run by a research community on a best-effort basis, the project says plainly that liboqs is not audited for high-security use, leaving production code to verified libraries such as the PQ Code Package’s.

Timeline

2014
Open Quantum Safe is founded at the University of Waterloo
2016
liboqs repository and the OQS fork of OpenSSL open in August
2021
oqs-provider for OpenSSL 3 is started
2024
Joins the Post-Quantum Cryptography Alliance at its launch on February 6; 0.12.0 adopts final ML-DSA
2025
0.13.0 makes mlkem-native the default ML-KEM (April); 0.15.0 removes Dilithium (November)
2026
0.16.0 (July 9) switches ML-DSA to mldsa-native and removes SPHINCS+

Sources8 · facts checked 28 October 2026

Improve this page on GitHub