Open Quantum Safe 后量子密码库 liboqs 上手指南:构建、示例与 TLS 接入【免费下载链接】liboqsC library for prototyping and experimenting with quantum-resistant cryptography项目地址: https://gitcode.com/GitHub_Trending/li/liboqsNIST 在 2024 年陆续发布 FIPS 203、204、205 三份最终标准,将 ML-KEM、ML-DSA、SLH-DSA 定为标准方案后,后量子密码(PQC,Post-Quantum Cryptography)正式从论文走进了工程议程。如果团队想提前评估这些抗量子算法,Open Quantum Safe(OQS)项目下的 liboqs 是目前最常用的一站:它是一套开源 C 语言库,把多种后量子密钥封装(KEM)与数字签名算法收进统一 API,并附带测试和性能基准工具,专门用于原型验证与算法评估。liboqs 支持哪些后量子算法liboqs 是 OQS 项目的核心库,OQS 由 Linux 基金会下的后量子密码联盟支持运营。项目提供的东西可以拆成三块:一批量子安全 KEM 与签名算法的开源实现、一套统一的 C API、以及配套的测试与基准测试工具。这里先解释一下 KEM:它负责让通信双方协商出一个对称密钥,可以理解成 Diffie-Hellman 的通用化版本,只是换成了抗量子的数学基础。算法覆盖面是当前版本的重点。NIST 已标准化的三族——密钥交换用 ML-KEM,签名用 ML-DSA 和 SLH-DSA——全部有实现,且算法名保持稳定;即使 NIST 调整实现细节,liboqs 也会同步适配。KEM 方向还收录了 FrodoKEM、HQC、Classic McEliece、BIKE、NTRU、NTRU-Prime 等,签名方向有 Falcon、MAYO、SNOVA、UOV、CROSS、MQOM 等,此外是 LMS 与 XMSS 两种有状态签名方案(分别对应 RFC 8554 和 RFC 8391)。每个算法的标准化状态、支持级别和平台优化情况汇总在 ALGORITHMS.md,每个算法族在 docs/algorithms/ 目录下还有单独详情页,选型前可以先看这里。如何构建 liboqs 并跑通第一个 KEM 示例以 Ubuntu 为例,先准备构建依赖:sudo apt install cmake ninja-build gcc libssl-dev推荐安装 OpenSSL 3.x;如果希望 liboqs 内部复用 OpenSSL 的 AES 与 SHA-2 实现,就必须带上它。然后拉取源码并构建:git clone https://gitcode.com/GitHub_Trending/li/liboqs cd liboqs mkdir build && cd build cmake -GNinja .. ninja默认构建产物是静态库liboqs.a;要生成共享库,给 cmake 追加-DBUILD_SHARED_LIBS=ON即可。启用或禁用某个算法族的构建选项记录在 CONFIGURE.md 中,也可以在 build 目录执行cmake -LAH -N ..查看全部选项。构建成功后,tests目录下会生成一批命令行工具,这是 liboqs 最好用的部分:test_kem、test_sig做功能测试,speed_kem、speed_sig做基准测试,example_kem、example_sig是最小的可运行示例。典型的评估流程是:先跑example_kem确认 API 可用,再用speed_kem拿到各参数集的耗时与密钥尺寸,内存敏感的场景还可以用test_kem_mem测内存占用。如何把 PQC 接入现有 TLS 栈liboqs 本身只提供算法,协议层集成靠 OQS 生态完成:OQS 提供了基于 OpenSSL 3 Provider 的原型集成,把 liboqs 接入 TLS、X.509 和 S/MIME。对已有系统意味着:基于 OpenSSL 的应用不必重写握手逻辑,加载该 Provider 就能协商后量子密钥交换,这是验证"量子安全 TLS"成本最低的路线。更稳妥的做法是混合加密:让 PQC 算法与传统公钥(如 RSA、椭圆曲线)并行工作,一方被攻破时另一方仍能兜底,整体安全性至少不低于纯传统方案。liboqs 的 README 也明确建议等待标准完全落地的团队优先采用混合模式。liboqs 适合谁:研究原型,而非生产环境直说边界:项目方声明 liboqs 面向研究与原型,不建议在生产环境或保护敏感数据时使用。这个判断是合理的——后量子算法整体经受的审查远不如 RSA 和椭圆曲线充分,HQC、Falcon 等算法族仍处于"已被选中、尚未定稿"的阶段,后续参数仍可能调整。所以它适合这样的团队:未来一两年需要评估 PQC 算法、想在自己硬件上实测密钥尺寸/耗时/内存、或在内网测试环境跑通 PQC 协商。不适合的,是把生产流量或长期机密数据直接押在它上面——等标准生态进一步成熟再上。最后一点合规提示:liboqs 本体采用 MIT 许可,但部分第三方算法实现携带各自许可证,重新分发前建议核对 README 中的许可清单。【免费下载链接】liboqsC library for prototyping and experimenting with quantum-resistant cryptography项目地址: https://gitcode.com/GitHub_Trending/li/liboqs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Open Quantum Safe 后量子密码库 liboqs 上手指南:构建、示例与 TLS 接入【免费下载链接】liboqsC library for prototyping and experimenting with quantum-resistant cryptography项目地址: https://gitcode.com/GitHub_Trending/li/liboqsNIST 在 2024 年陆续发布 FIPS 203、204、205 三份最终标准,将 ML-KEM、ML-DSA、SLH-DSA 定为标准方案后,后量子密码(PQC,Post-Quantum Cryptography)正式从论文走进了工程议程。如果团队想提前评估这些抗量子算法,Open Quantum Safe(OQS)项目下的 liboqs 是目前最常用的一站:它是一套开源 C 语言库,把多种后量子密钥封装(KEM)与数字签名算法收进统一 API,并附带测试和性能基准工具,专门用于原型验证与算法评估。liboqs 支持哪些后量子算法liboqs 是 OQS 项目的核心库,OQS 由 Linux 基金会下的后量子密码联盟支持运营。项目提供的东西可以拆成三块:一批量子安全 KEM 与签名算法的开源实现、一套统一的 C API、以及配套的测试与基准测试工具。这里先解释一下 KEM:它负责让通信双方协商出一个对称密钥,可以理解成 Diffie-Hellman 的通用化版本,只是换成了抗量子的数学基础。算法覆盖面是当前版本的重点。NIST 已标准化的三族——密钥交换用 ML-KEM,签名用 ML-DSA 和 SLH-DSA——全部有实现,且算法名保持稳定;即使 NIST 调整实现细节,liboqs 也会同步适配。KEM 方向还收录了 FrodoKEM、HQC、Classic McEliece、BIKE、NTRU、NTRU-Prime 等,签名方向有 Falcon、MAYO、SNOVA、UOV、CROSS、MQOM 等,此外是 LMS 与 XMSS 两种有状态签名方案(分别对应 RFC 8554 和 RFC 8391)。每个算法的标准化状态、支持级别和平台优化情况汇总在 ALGORITHMS.md,每个算法族在 docs/algorithms/ 目录下还有单独详情页,选型前可以先看这里。如何构建 liboqs 并跑通第一个 KEM 示例以 Ubuntu 为例,先准备构建依赖:sudo apt install cmake ninja-build gcc libssl-dev推荐安装 OpenSSL 3.x;如果希望 liboqs 内部复用 OpenSSL 的 AES 与 SHA-2 实现,就必须带上它。然后拉取源码并构建:git clone https://gitcode.com/GitHub_Trending/li/liboqs cd liboqs mkdir build && cd build cmake -GNinja .. ninja默认构建产物是静态库liboqs.a;要生成共享库,给 cmake 追加-DBUILD_SHARED_LIBS=ON即可。启用或禁用某个算法族的构建选项记录在 CONFIGURE.md 中,也可以在 build 目录执行cmake -LAH -N ..查看全部选项。构建成功后,tests目录下会生成一批命令行工具,这是 liboqs 最好用的部分:test_kem、test_sig做功能测试,speed_kem、speed_sig做基准测试,example_kem、example_sig是最小的可运行示例。典型的评估流程是:先跑example_kem确认 API 可用,再用speed_kem拿到各参数集的耗时与密钥尺寸,内存敏感的场景还可以用test_kem_mem测内存占用。如何把 PQC 接入现有 TLS 栈liboqs 本身只提供算法,协议层集成靠 OQS 生态完成:OQS 提供了基于 OpenSSL 3 Provider 的原型集成,把 liboqs 接入 TLS、X.509 和 S/MIME。对已有系统意味着:基于 OpenSSL 的应用不必重写握手逻辑,加载该 Provider 就能协商后量子密钥交换,这是验证"量子安全 TLS"成本最低的路线。更稳妥的做法是混合加密:让 PQC 算法与传统公钥(如 RSA、椭圆曲线)并行工作,一方被攻破时另一方仍能兜底,整体安全性至少不低于纯传统方案。liboqs 的 README 也明确建议等待标准完全落地的团队优先采用混合模式。liboqs 适合谁:研究原型,而非生产环境直说边界:项目方声明 liboqs 面向研究与原型,不建议在生产环境或保护敏感数据时使用。这个判断是合理的——后量子算法整体经受的审查远不如 RSA 和椭圆曲线充分,HQC、Falcon 等算法族仍处于"已被选中、尚未定稿"的阶段,后续参数仍可能调整。所以它适合这样的团队:未来一两年需要评估 PQC 算法、想在自己硬件上实测密钥尺寸/耗时/内存、或在内网测试环境跑通 PQC 协商。不适合的,是把生产流量或长期机密数据直接押在它上面——等标准生态进一步成熟再上。最后一点合规提示:liboqs 本体采用 MIT 许可,但部分第三方算法实现携带各自许可证,重新分发前建议核对 README 中的许可清单。【免费下载链接】liboqsC library for prototyping and experimenting with quantum-resistant cryptography项目地址: https://gitcode.com/GitHub_Trending/li/liboqs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考