liboqs

liboqs is an open source C library that provides a unified API for post-quantum key encapsulation mechanisms and digital signatures. It is the core library of the Open Quantum Safe (OQS) project, hosted since 2024 by the Post-Quantum Cryptography Alliance under the Linux Foundation, and is widely used to prototype and benchmark post-quantum cryptography in protocols and applications.

#What the library provides

liboqs wraps many algorithm implementations behind two object types, OQS_KEM and OQS_SIG, so an application can select an algorithm by name at runtime and call the same key generation, encapsulation, decapsulation, signing, and verification functions regardless of the underlying scheme. Supported algorithms include the NIST standards ML-KEM, ML-DSA, and SLH-DSA, the fourth-round selection HQC, Falcon (the planned FN-DSA / Falcon), and alternates such as FrodoKEM, Classic McEliece, and BIKE, plus candidates from NIST's additional signature evaluation, including MAYO and CROSS. The full list per release is documented in the liboqs repository.

The project does not write most implementations from scratch. A copy_from_upstream workflow pulls code from vetted upstream sources, most notably PQClean and official reference implementations, and integrates them under the common API. The library builds on x86-64 and ARM platforms, uses optimized AVX2 or NEON code paths where available, ships known-answer tests, and includes speed-testing utilities that have made it a common baseline for published benchmarks. liboqs is MIT licensed.

#Language wrappers

The same GitHub organization maintains official wrappers that expose the C library to other languages: liboqs-python, liboqs-go, liboqs-rust, liboqs-java, and liboqs-dotnet. Each wrapper calls into the native library, so algorithm coverage tracks the underlying liboqs version. Links to all wrappers are collected on the Open Quantum Safe site.

#Protocol integrations

The most consequential integration is oqs-provider, a dynamically loadable provider for OpenSSL 3. It plugs liboqs algorithms into OpenSSL's provider interface, enabling post-quantum and hybrid key exchange in TLS 1.3 as well as post-quantum X.509 certificates, without patching OpenSSL. Before OpenSSL 3, the project maintained a patched OQS-OpenSSL 1.1.1 fork for the same purpose. Since OpenSSL 3.5 added native support for ML-KEM, ML-DSA, and SLH-DSA, oqs-provider matters mainly for algorithms OpenSSL does not ship and for research builds.

The project also maintains OQS-BoringSSL and OQS-OpenSSH, forks of BoringSSL and OpenSSH with liboqs wired into their handshakes. These forks have served as prototyping vehicles for post-quantum TLS and post-quantum SSH experiments and for interoperability testing between independent implementations.

#Governance: from academic project to the PQCA

OQS was founded around 2016 by Douglas Stebila and Michele Mosca, then both associated with the University of Waterloo, with the design goals described in their paper Post-quantum key exchange for the Internet and the Open Quantum Safe project. For its first eight years the project ran as an academic open source effort that tracked the NIST Post-Quantum Cryptography Standardization process, adding and removing algorithms as the competition progressed.

In February 2024 the Linux Foundation announced the Post-Quantum Cryptography Alliance (PQCA), an open foundation for post-quantum software, with OQS as a founding project. Founding members included AWS, Cisco, Google, IBM, NVIDIA, and the University of Waterloo, among others. The move gave the project neutral governance, funding, and a security response structure beyond what a university team could sustain.

#From research prototype to production hardening

For most of its history, liboqs documentation explicitly warned that the library was designed for research and prototyping and recommended against relying on it in production environments. That caution reflected real trade-offs: rapidly changing algorithms, upstream code of varying maturity, and limited resources for audits.

Under the PQCA the trajectory has shifted toward production hardening. Constant-time behavior is tested in continuous integration, releases follow a defined security response process, and the library has been adopting production-grade components where they exist. The clearest example is mlkem-native, a standalone ML-KEM implementation developed under the PQCA's PQ Code Package project with machine-checked proofs for parts of its code, which liboqs has adopted as its ML-KEM implementation as of early 2026. Even so, the project's own guidance still steers production TLS deployments toward natively supported implementations; a comparison of the options appears in post-quantum cryptography libraries. For teams building cryptographically agile systems, liboqs remains the fastest way to evaluate many post-quantum algorithms behind one API.