liboqs 通过同一套 C API 汇集了后量子密钥封装机制(OQS_KEM)和签名方案(OQS_SIG)的实现,也是 OpenSSL 3 的 Open Quantum Safe 提供程序的引擎。本页的事实基于 0.16.0 版(提交 5a1a854b0dc9)检查得出,构建时使用默认的 CMake 选项,即由 OpenSSL 提供对称原语。README 用全大写英文写着:“我们目前不建议在生产环境中依赖此库,也不建议用它保护任何敏感数据。”如需在生产环境中使用 ML-KEM 和 ML-DSA,可以参阅 OpenSSL、BoringSSL、AWS-LC 和 Bouncy Castle 页面,其中列出了它们的主 API 提供哪些算法。
默认构建启用了 41 个 KEM 和 221 个签名参数集,每个算法族都有一个参数集完成了完整的往返测试:NIST 标准 ML-KEM、ML-DSA 和 SLH-DSA(156 个 SLH-DSA 变体,包括纯模式和预哈希模式),Falcon,KEM 候选算法 HQC、Classic McEliece、FrodoKEM、BIKE、NTRU 和 sntrup761,标准化之前的 Kyber,以及附加签名候选算法 MAYO、CROSS、UOV、SNOVA 和 MQOM。新代码中应使用 ML-KEM-768 这个名称,而不是 Kyber768。默认构建没有启用任何 XMSS 或 LMS 参数集。
ML-DSA 签名采用对冲方式:用同一密钥对同一消息生成的两个签名不同,因此测试必须验证签名,而不能比较字节。FIPS 204 上下文字符串通过 OQS_SIG_sign_with_ctx_str 支持;在上下文 invoice-v1 下生成的签名,用 invoice-v2 验证失败,改用普通的 OQS_SIG_verify(它使用空上下文)验证也失败,因此双方必须约定同一个上下文。截断的签名、3 字节的数据块,以及针对其他数据的有效签名,返回的都是同一个 OQS_ERROR。
ML-KEM 解封装不会报告密文损坏:密文翻转一位后,OQS_KEM_decaps 返回 OQS_SUCCESS 和一个不同的共享密钥,这正是 FIPS 203 的隐式拒绝所要求的。只有在使用派生出的密钥时才会暴露不匹配,例如表现为 AEAD 解密失败。该函数也不接收密文长度参数,而是恰好读取 length_ciphertext 字节,ML-KEM-768 为 1088 字节。可以在 ML-KEM 工具和后量子签名工具中试用这两种方案。