Skip to content

SYSTEM Cited by 1 source

LibOQS (liboqs)

What

LibOQS is an open-source C library providing implementations of post-quantum cryptographic primitives — KEMs and signatures — under a single unified API. Developed by the Open Quantum Safe (OQS) consortium (since 2019), now part of the Linux Foundation Post-Quantum Cryptography Alliance (PQCA). LibOQS is the de-facto reference implementation substrate that higher-level TLS / SSH / messaging libraries integrate against to get PQ primitives.

(Source: sources/2026-04-16-meta-post-quantum-cryptography-migration-at-meta-framework-lesson)

Why it matters: implementation maturity ≠ algorithm maturity

Meta names LibOQS explicitly in its three-external-dependencies migration model under production-level PQC implementations:

Most cryptography-related vulnerabilities are not due to any flaws in the algorithms, but instead in their implementations, which may contain bugs or subtle side-channel vulnerabilities. Getting all these things right isn't trivial. The good news is that the cryptography community has already been working on this front for quite some time. Since 2019, the Open Quantum Safe consortium, part of the Linux Foundation Post-Quantum Cryptography Alliance, has been developing LibOQS, a PQC cryptography library. LibOQS is starting to be integrated by industry organizations. (Source: sources/2026-04-16-meta-post-quantum-cryptography-migration-at-meta-framework-lesson)

The premise: an organisation cannot migrate to PQC ahead of the algorithm-implementation ecosystem. Waiting until vetted, side- channel-hardened implementations exist is a load-bearing part of the dependency chain — which is why the PQCA / LibOQS surface is a named migration-blocking external dependency, not just a background concern.

Primitives shipped

As of 2026 LibOQS ships implementations of:

  • KEMs: ML-KEM (Kyber), Streamlined NTRU Prime, HQC, BIKE, Classical McEliece, FrodoKEM.
  • Signatures: ML-DSA (Dilithium), SLH-DSA (SPHINCS+), Falcon, plus candidate schemes being evaluated.

Each primitive has multiple parameter sets matching the NIST security categories.

How it's consumed

  • OpenSSL provider (oqs-provider) — plugs into OpenSSL 3.x to expose PQ primitives as regular OpenSSL algorithms.
  • OpenSSH integration — hybrid KEX modes using LibOQS-backed KEMs.
  • BoringSSL / rustls / language bindings — multiple downstream integrations.

Meta's contribution

Meta is a PQCA member and "actively working with LibOQS leads, including fixing bugs in the library and continuously providing feedback." An example contribution is [LibOQS issue

1548](https://github.com/open-quantum-safe/liboqs/issues/1548)

cited in the Meta post. The broader pattern is Meta investing in the OSS-substrate its migration depends on — consistent with Meta's foundational-OSS stewardship discipline (see systems/jemalloc for the same pattern on memory allocators, systems/ffmpeg for the same on video codecs).

Trust-root considerations

LibOQS is currently not FIPS-validated. FIPS-regulated deployments must use FIPS-validated PQ implementations — which as of 2026 is a separate track with its own timeline. Organisations deploying LibOQS must choose between:

  • LibOQS + non-FIPS deployment — broader primitive support, earlier availability.
  • FIPS-validated vendor implementations — narrower primitive support, later availability.

This is the implementation-side analogue of the algorithm-side FIPS gap (e.g. Streamlined NTRU Prime excluded from US-region GHEC SSH).

Seen in

Last updated · 319 distilled / 1,201 read