抗量子就绪状态 (Post-Quantum Readiness)

FIBEMATE 技术文档 · 2026-06-16 · 公开透明 · 持续更新

🔐

FIBEMATE 当前抗量子状态

✅ PQC-Ready → ⬜ PQC-Active

ML-KEM-768 (FIPS 203) 已完整实现并通过验证，但尚未集成到 TLS 1.3 握手。这是一个诚实的中间状态："准备好了"≠"正在抗量子"。

1. "PQC-Ready" 是什么意思

FIBEMATE 当前处于 "PQC-Ready"（抗量子就绪）状态——这与"PQC-Active（正在抗量子）"有明确区别：

✅ 已完成

⬜ 待完成：通往 "PQC-Active"

简单来说：我们已经造好了零件（ML-KEM-768、SM2 优化），但还没把它们装进汽车引擎（TLS 1.3 握手）。

2. 组件状态总表

组件状态说明
ML-KEM-768 实现 ✅ 完成 纯 JS + WASM 双版本，PQC 标准 FIPS 203 兼容
KAT 验证 (10,000 轮) ✅ 完成 100% 通过，KeyGen / Encaps / Decaps 全覆盖
SM2-MLKEM-768 混合协议 ✅ 设计完成 IANA #4590 已分配，IEEE 论文已发表
SM2 性能优化 ✅ 完成 5 阶段优化，wNAF (w=4) 已集成
FPGA NTT 单元 ✅ 原型完成 硬件侧 ML-KEM / SM2 共享 NTT 计算单元
WASM 移植 (pq-wasm) ✅ 完成 Rust → WASM 编译管线，1.87ms/轮
TLS 1.3 混合握手集成 ⬜ 待开始 Nginx / Node.js TLS 栈集成
ClientHello #4590 扩展 ⬜ 待开始 依赖 TLS 栈对 NamedGroup 4590 的原生支持
端到端 TLS 测试 ⬜ 待开始 浏览器 ↔ Nginx ↔ Node.js 全链路
生产 fibemate.net 启用 ⬜ 待开始 当前使用标准 SM2 证书

整体进度：约 65%（核心算法 100%，系统集成 0%）

3. 差距分析：从 "Ready" 到 "Active"

从 PQC-Ready 到 PQC-Active 的差距集中在 TLS 1.3 握手层。以下是具体的技术路径：

3.1 混合握手流程（目标状态）

Client                                                Server
  |                                                     |
  |--- ClientHello ──────────────────────────────────>  |
  |    (supported_groups: [4590, ...])                  |
  |    (key_share[4590]: ML-KEM-768 public key)         |
  |                                                     |
  |                      ServerHello ─────────────────>  |
  |                      (key_share[4590]: ciphertext)   |
  |                                                     |
  |  shared_secret = Decaps(ct, sk)                     |
  |  = Encaps(pk) 的 output                             |
  |                                                     |
  |  <========== SM2-MLKEM-768 Hybrid TLS 1.3 ========>  |

3.2 七步迁移路径

1
确认 TLS 栈对 NamedGroup #4590 的支持
查阅 Nginx / Node.js TLS 库对自定义命名组的扩展能力。可能需 patch 或 fork。
2
实现 ClientHello 扩展
在 TLS ClientHello 的 supported_groups 中携带 #4590，附带 ML-KEM-768 公钥（~1184 字节）。
3
测试 ClientHello 长度
~1249 字节的 ML-KEM-768 公钥是否被中间件/防火墙/CGNAT 截断？需实际网络测试。
4
实现服务端混合密钥交换
ServerHello 中回复 ML-KEM-768 密文；双方导出共享密钥，与 SM2 密钥交换结果混合。
5
端到端测试
浏览器 ↔ Nginx ↔ Node.js 后端完整链路测试，验证混合握手建立。
6
性能基准
对比纯 SM2 vs SM2+ML-KEM-768 握手时间。目标：混合握手 < 10ms。
7
生产部署 & 长期监控
fibemate.net 切换为混合握手，长期监控兼容性和性能。

3.3 风险与缓解

风险影响缓解措施
Nginx/Node.js 不支持 #4590需 patch TLS 库预研 OpenSSL fork 或自定义 TLS 扩展
ClientHello 被中间件截断握手失败准备 TCP 分段策略；降级到纯 SM2
ML-KEM-768 公钥过大首包载荷增加 ~1.2KB可接受——等效于一张小图片
混合密钥交换性能不达标用户体验受影响WASM 加速；FPGA 硬件卸载
💡 关键观察：ML-KEM-768 的封装/解封装本身仅 ~1-2ms。瓶颈可能在 TLS 库适配和网络往返，而非密码运算。这使工程风险可控。

4. 时间线预估

阶段内容预估依赖
第 1 周 发布本页面 + 研读 TLS 栈文档 2-4 小时 无
第 1–2 周 步骤 1-2：TLS 栈评估 + ClientHello 扩展原型 3-5 天 文档查阅
第 2–3 周 步骤 3-4：ClientHello 测试 + 服务端混合密钥交换 5-7 天 步骤 1-2
第 3–4 周 步骤 5-7：端到端测试 + 性能基准 + 部署 3-5 天 步骤 3-4

⏱ 总计：2–4 周（取决于 TLS 栈适配复杂度）

5. 常见问题

Q: FIBEMATE 现在是"抗量子"的吗？

A: 诚实回答：还不是。ML-KEM-768 算法已完整实现并通过 KAT 验证，但尚未集成到 TLS 1.3。这意味着我们"做好了准备"，但当前实际的网络通信仍依赖于经典密码学（SM2）。请关注本页面的进度更新。

Q: 什么时候能实现真正的抗量子通信？

A: 预计 2–4 周内完成 TLS 1.3 混合握手集成，届时 fibemate.net 将提供 SM2-MLKEM-768 混合加密。具体时间取决于 TLS 栈（Nginx/Node.js）的适配复杂度。

Q: 为什么 ML-KEM-768 算法就绪了却不能直接用？

A: 因为抗量子不只是一个"算法库"问题——它需要在 TLS 握手的真实网络环境中运行。ClientHello 需要正确携带 ML-KEM-768 公钥，ServerHello 需要回复密文，双方需要用混合密钥材料导出 AES-GCM / SM4 会话密钥。这些都需要 TLS 栈的原生支持或定制扩展。

Q: 当前 fibemate.net 用什么加密？

A: 当前使用 SM2 ECC + ECDHE 进行密钥交换，TLS 1.3。这是经典安全级别（~128-bit），不能抵抗量子计算机攻击。详见 安全性验证页面。

Q: ML-KEM-768 的 KAT 测试通过意味着什么？

A: 意味着我们的 ML-KEM-768 实现与 NIST FIPS 203 参考实现严格一致——10,000 轮随机输入的 KeyGen / Encaps / Decaps 结果与官方已知答案 100% 匹配。这证明了算法实现的正确性，但不等同于"已经在用了"。查看 KAT 报告 →

Q: X-Wing (X25519+ML-KEM-768) 和 SM2-MLKEM-768 有什么区别？

A: X-Wing（IANA #4588）是国际路线，X25519 + ML-KEM-768 混合。SM2-MLKEM-768（IANA #4590）是中国自主路线，满足国密合规（等保 2.0 / 密评要求）。两者后量子安全强度相同（共享 ML-KEM-768），经典部分不同（X25519 vs SM2）。详见 安全性页面第 8 节 →

Q: 我能参与或贡献吗？

A: FIBEMATE 尚未开源（计划 2026 年 8 月）。目前您可以关注本页面的进度，或通过社区渠道了解最新动态。技术反馈欢迎发送至项目邮箱。

6. 相关页面