PQC Implementations & Libraries
A practical map of the open-source and commercial libraries that ship post-quantum KEMs and signatures today, plus guidance on which to pick for your language, platform, and compliance needs.
The landscape
Post-quantum cryptography moved from research code to production libraries quickly. There are two broad camps: research/aggregation projects that expose every NIST candidate behind a uniform API (most notably the Open Quantum Safe project and liboqs), and mainstream TLS/crypto stacks that have folded the finalized FIPS algorithms into their core (OpenSSL, BoringSSL, AWS-LC, wolfSSL, Bouncy Castle, Botan).
The single most important development is OpenSSL 3.5 (2025), which ships native ML-KEM, ML-DSA, and SLH-DSA — no third-party provider required for the FIPS algorithms. For experimental or not-yet-standardized schemes (Classic McEliece, HQC, BIKE, Falcon), you still reach for liboqs and its oqs-provider. Note that Falcon / FN-DSA has been selected for a future FIPS standard but is not yet a final FIPS standard; for production compliance, prefer ML-DSA / SLH-DSA unless your policy explicitly allows Falcon.
Library matrix
KEM = key encapsulation; Sig = digital signatures. "FIPS-validated?" refers to a CMVP/FIPS 140-3 certificate covering the PQC algorithms specifically — most are still in progress as of 2025–2026, so verify the current certificate before claiming compliance.
| Library | Language | KEMs | Signatures | FIPS-validated? | Notes |
|---|---|---|---|---|---|
| liboqs (OQS) | C (wrappers for Python/Go/Rust/Java/.NET/C++) | ML-KEM, Classic McEliece, HQC, BIKE, FrodoKEM | ML-DSA, SLH-DSA, Falcon, XMSS/LMS (via others) | No (research aggregation) | Widest algorithm coverage; uniform API; great for prototyping and benchmarking. The exact algorithm list is per oqs.get_enabled_*_mechanisms() or the liboqs build configuration; liboqs's algorithm enablement changes across versions. |
| OpenSSL 3.5+ | C | ML-KEM (native) | ML-DSA, SLH-DSA (native) | Per the current CMVP certificate and security policy of the OpenSSL FIPS provider. (OpenSSL 3.5.4 was submitted for FIPS 140-3 validation in Oct 2025; the CMVP certificate is still pending.) | Native FIPS algorithms; oqs-provider adds the rest. The default choice for TLS. OpenSSL 3.5+ natively supports the FIPS 203/204/205 algorithms; whether it can be used for FIPS 140-3 compliance depends on checking the specific FIPS provider, module version, certificate number, and parameter-set boundary. |
| BoringSSL | C/C++ | ML-KEM | Limited | Not a general-purpose FIPS distribution; the actual compliance boundary is per Google's product documentation. | Powers Chrome/Android; hybrid X25519+ML-KEM in production. |
| AWS-LC | C | ML-KEM | ML-DSA | AWS-LC FIPS module / CMVP status is per the current certificate; ML-KEM is within the scope of the AWS-LC FIPS 3.0 validation description. | Amazon's libcrypto fork; used across AWS services and s2n-tls. |
| wolfSSL | C | ML-KEM | ML-DSA, SLH-DSA, XMSS/LMS | per wolfSSL's current FIPS module CMVP certificate and security policy | Embedded/IoT focus; small footprint. |
| Bouncy Castle | Java, C# | ML-KEM, others | ML-DSA, SLH-DSA, Falcon, XMSS/LMS | Module-dependent | The de-facto PQC stack for JVM and .NET applications. |
| Botan | C++ | ML-KEM, FrodoKEM, others | ML-DSA, SLH-DSA, XMSS | No | Broad algorithm support with a modern C++ API. |
| libgcrypt | C | ML-KEM | ML-DSA, SLH-DSA | Module-dependent | GnuPG's crypto library; PQC support landing incrementally. |
| PQClean | C (reference) | ML-KEM and candidates | ML-DSA, SLH-DSA, Falcon | N/A (source) | Clean, portable reference C consumed by many of the libraries above. |
| NIST reference | C | ML-KEM | ML-DSA, SLH-DSA | N/A (spec) | The authoritative implementations that ship with the FIPS standards and KATs. |
How to choose
- General-purpose server TLS/HTTPS migration? Consider OpenSSL 3.5+ first, or a distribution from a vendor that has integrated equivalent capability; compliance scenarios still require verifying the FIPS provider's certificate boundary.
- Need an experimental KEM (Classic McEliece, HQC, BIKE)? Use liboqs /
oqs-provider. - JVM or .NET? Bouncy Castle is the mature path.
- Embedded / constrained device? wolfSSL or PQClean-derived code, watching code size and stack usage.
- Need FIPS 140-3 compliance? Pin to a module with an active CMVP certificate covering the exact algorithm and parameter set — and re-check, because certificates are landing throughout 2025–2026.
- Prototyping or benchmarking many schemes? liboqs gives you all of them behind one API.
A note on hybrids
Most production deployments run PQC in hybrid mode — a classical algorithm combined with a post-quantum one (e.g. X25519MLKEM768). All the major TLS libraries above support hybrid key exchange, which hedges against an undiscovered flaw in either component.
Related
liboqs →
Install and use the OQS C library and Python wrapper.
OpenSSL →
Native PQC in OpenSSL 3.5 and the oqs-provider.
Testing & validation →
ACVP, KATs, and FIPS 140-3.
Performance →
CPU vs bandwidth tradeoffs across schemes.
Standards & references
- Open Quantum Safe — umbrella project aggregating PQC implementations behind a uniform API.
- liboqs (GitHub) — the core C library with the widest algorithm coverage.
- PQClean — clean, portable reference C consumed by many libraries above.
- oqs-provider — plugs liboqs algorithms into OpenSSL 3.
- Resources — full standards register
PQC 实现与开源库
本页梳理当前已可用于生产的后量子 KEM 与签名库，开源与商业兼顾，并给出按语言、平台、合规需求选型的实用建议。
整体格局
后量子密码从研究代码走向生产库的速度很快。整体可分为两大阵营：一类是研究聚合型项目，用统一 API 暴露所有 NIST 候选算法，代表是 Open Quantum Safe 项目及其 liboqs；另一类是主流 TLS 密码栈，已把最终定稿的 FIPS 算法纳入核心，如 OpenSSL、BoringSSL、AWS-LC、wolfSSL、Bouncy Castle 与 Botan。
其中最关键的进展是 OpenSSL 3.5（2025 年版），它原生内置了 ML-KEM、ML-DSA 与 SLH-DSA，使用这些 FIPS 算法不再需要第三方 provider。而对于尚未标准化或仍属实验性的算法（Classic McEliece、HQC、BIKE、Falcon），则仍需借助 liboqs 及其 oqs-provider。需要特别说明的是，Falcon / FN-DSA 已入选未来 FIPS 标准，但尚未成为最终 FIPS 标准；除非你的策略明确允许 Falcon，生产合规应优先 ML-DSA / SLH-DSA。
开源库对照表
KEM 指密钥封装，Sig 指数字签名。“是否 FIPS 验证”一栏针对的是 PQC 算法本身的 CMVP/FIPS 140-3 证书，截至 2025 至 2026 年多数仍在办理，对外声称合规前务必核对当前有效证书。
| 库 | 语言 | KEM | 签名 | 是否 FIPS 验证 | 说明 |
|---|---|---|---|---|---|
| liboqs OQS | C 含 Python/Go/Rust/Java/.NET/C++ 封装 | ML-KEM Classic McEliece HQC BIKE FrodoKEM | ML-DSA SLH-DSA Falcon XMSS/LMS | 否 研究聚合 | 算法覆盖最广，统一 API，适合原型与基准测试。具体算法列表以 oqs.get_enabled_*_mechanisms() 或 liboqs 编译配置为准；liboqs 的算法启用状态会随版本变化。 |
| OpenSSL 3.5+ | C | ML-KEM 原生 | ML-DSA SLH-DSA 原生 | 以 OpenSSL FIPS provider 当前 CMVP 证书和安全策略为准。（OpenSSL 3.5.4 已于 2025 年 10 月提交 FIPS 140-3 验证，CMVP 证书仍在办理。） | 原生 FIPS 算法，其余由 oqs-provider 补充，TLS 首选。OpenSSL 3.5+ 原生支持 FIPS 203/204/205 算法；是否可用于 FIPS 140-3 合规，应核对具体 FIPS provider、模块版本、证书编号和参数集边界。 |
| BoringSSL | C/C++ | ML-KEM | 有限 | 非通用 FIPS 分发库；实际合规边界以 Google 产品说明为准。 | 支撑 Chrome 与 Android，生产中使用 X25519+ML-KEM 混合 |
| AWS-LC | C | ML-KEM | ML-DSA | AWS-LC FIPS 模块 / CMVP 状态以当前证书为准；ML-KEM 已进入 AWS-LC FIPS 3.0 验证说明范围。 | 亚马逊的 libcrypto 分支，用于 AWS 服务与 s2n-tls |
| wolfSSL | C | ML-KEM | ML-DSA SLH-DSA XMSS/LMS | 以 wolfSSL FIPS 模块当前 CMVP 证书和安全策略为准。 | 面向嵌入式与 IoT，体积小 |
| Bouncy Castle | Java C# | ML-KEM 及其他 | ML-DSA SLH-DSA Falcon XMSS/LMS | 视模块而定 | JVM 与 .NET 事实标准 PQC 栈 |
| Botan | C++ | ML-KEM FrodoKEM 等 | ML-DSA SLH-DSA XMSS | 否 | 算法支持广，现代 C++ API |
| libgcrypt | C | ML-KEM | ML-DSA SLH-DSA | 视模块而定 | GnuPG 密码库，PQC 支持逐步落地 |
| PQClean | C 参考 | ML-KEM 及候选 | ML-DSA SLH-DSA Falcon | 不适用 源码 | 干净可移植的参考 C 实现，上述多数库都引用它 |
| NIST 参考实现 | C | ML-KEM | ML-DSA SLH-DSA | 不适用 规范 | 随 FIPS 标准与 KAT 一同发布的权威实现 |
如何选型
- 通用服务器 TLS/HTTPS 迁移：优先考虑 OpenSSL 3.5+ 或厂商已集成同等能力的发行版；合规场景仍需核对 FIPS provider 证书边界。
- 需要实验性 KEM（Classic McEliece、HQC、BIKE）：用 liboqs 配合
oqs-provider。 - JVM 或 .NET：Bouncy Castle 最成熟。
- 嵌入式或受限设备：选 wolfSSL，或基于 PQClean 的代码，重点关注代码体积与栈占用。
- 需要 FIPS 140-3 合规：锁定一个持有有效 CMVP 证书、且证书覆盖具体算法与参数集的模块，并反复核对——证书在 2025 至 2026 年间陆续发放。
- 原型或多方案基准测试：liboqs 用一套 API 提供全部算法。
关于混合模式
多数生产部署以混合模式运行 PQC，即把经典算法与后量子算法组合在一起，例如 X25519MLKEM768。上述主流 TLS 库均支持混合密钥交换，以防其中任一组件日后被发现缺陷。
相关
liboqs →
安装与使用 OQS C 库及 Python 封装
OpenSSL →
OpenSSL 3.5 原生 PQC 与 oqs-provider
测试与验证 →
ACVP KAT 与 FIPS 140-3
性能 →
各方案的算力与带宽权衡
标准与参考
- Open Quantum Safe — 用统一 API 聚合各类 PQC 实现的总括项目
- liboqs (GitHub) — 算法覆盖最广的核心 C 库
- PQClean — 干净可移植的参考 C 上述多数库均引用
- oqs-provider — 把 liboqs 算法接入 OpenSSL 3
- 资源链接 — 完整标准登记册