🔐 安全验证

• 算法：ML-KEM-768 (NIST FIPS 203，原 CRYSTALS-Kyber)
• 实现：JavaScript 运行时版本 + Rust/WASM NTT 优化版本
• 安全性：IND-CPA 安全 + 隐式拒绝 (Implicit Rejection)
• 密钥生命周期：私钥仅存在于浏览器内存，会话结束即销毁，永不存储

800/800 循环验证通过

• JS keygen reproducibility: 200/200 ✅
• WASM keygen reproducibility: 200/200 ✅
• JS encap reproducibility: 100/100 ✅
• WASM encap reproducibility: 100/100 ✅
• JS round-trip: 100/100 ✅
• WASM round-trip: 100/100 ✅

📌 同一种子输入 → 完全相同的密钥对和共享密钥输出。
跨实现 (JS vs WASM) 的二进制差异由 FIPS 203 §12.1 允许，不影响安全性。

信任边界断言语录：

• ✅ 私钥仅浏览器内存、会话结束即销毁
• ✅ 服务端完全入侵无法解密（历史+未来消息）
• ✅ 零知识认证确保服务端不获知密钥
• ⚠️ 浏览器环境（XSS/扩展/0-day）不在 TCB 内，由用户负责

🧠 完整威胁模型（威胁模型文档待更新）。

所有核心实现文件已通过 DigiCert 签发 RFC 3161 时间戳，确保代码在特定时间点的完整性可被第三方验证。

• 存证数量：122 份 RFC 3161 时间戳（DigiCert 签发，核心序列 lg-001~071 + lg-074~078（76 份） + 独立模块存证）
• 存证位置：/docs/tsa/（按日期分子目录，跨度 2026-06-25 ~ 2026-07-16）
• 验证命令：openssl ts -verify -in *.tsr -CAfile digicert.pem -untrusted chain.pem

📥 存证清单已归档至 /docs/tsa/

FIBEMATE 于 2026 年 8 月底 开源。届时你可以：

1. 自行构建并运行测试套件
2. 验证时间戳存证与源码哈希的匹配性
3. 审计所有密码学实现

git clone https://github.com/fibemate/fibemate
npm install
npm run test:formal # Track 1
npm run test:cross-lang # Track 2
npm run test:fips # Track 3
npm run test:seeded # 800/800 reproducibility

三者不是竞争关系，而是不同层次的互补组件——ML-KEM-768 负责"安全通道建立"，SM3/SM4 负责"通道内数据保护"。不在同一个维度上，不存在"哪个更好"的问题。

混合 KEM 有两种主流编号：

📌 FIBEMATE 选择 4590 路线，因 SM2 已通过国密合规与 TVLA 侧信道验证，与 ML-KEM-768 混合可在不引入新密码学假设的前提下完成抗量子升级。

🔧 实现路径：路径 C-2（应用层混合 KEX）——在 TLS 之上通过 TLS Exporter + HTTP POST 完成 SM2 与 ML-KEM-768 的共享密钥混合，绕过 Nginx/OpenSSL 原生改造，功能完整且可审计。

目标：让 SM2-MLKEM-768 混合握手在 延迟与流量 上追平 X25519MLKEM768（路径 A），同时保留国密合规优势。

9.1 基准对照（X25519MLKEM768 参考）

9.2 当前实现（路径 C-2 应用层）

📌 延迟差距来自应用层混合的两次往返，可通过 TLS Exporter 预计算 与 SM2 签名批处理 进一步压缩。

9.3 延迟优化路径

• 预计算：ML-KEM-768 封装在连接建立前完成（客户端空闲期）
• 并行化：SM2 签名与 ML-KEM 解封并行执行
• 缓存：会话恢复时复用混合主密钥，握手降为 1-RTT

9.4 流量优化路径

• SM2 公钥压缩：从 65B → 33B（仅传 Y 坐标 + 奇偶位）
• 混合密文复用：ML-KEM 密文与 SM2 密文共享 IV
• Header 压缩：HPACK 复用减少重复扩展字段

🎯 目标：延迟差距 < 15 ms，流量差距 < 5%，在保留国密合规前提下追平路径 A。

9.5 兼容性边界

• Chrome / Edge：路径 C-2 纯应用层，无 ClientHello 扩展，100% 兼容
• 旧网关：不修改 TLS 记录层，仅 HTTPS 应用数据，不会被中间盒丢弃
• 移动端：Expo 端到端 11/11 通过，混合握手延迟 < 100 ms

9.6 混合握手实现状态

✅ 路径 C-2 已上线（reg-server 集成，IANA #4590，10/10 集成测试通过）。
⚠️ 路径 A（TLS 层原生混合）于 2026-07-10 搁置——Nginx + oqs-provider 需 OpenSSL 3.2+，当前 3.0.13 不支持，且无混合协商回调 API。

9.7 密钥生命周期集成

混合会话密钥已接入密钥生命周期管理 v2（PBKDF2 + AES-GCM-256，IndexedDB v2）：

• identity_sm2 / identity_mlkem：180 天
• signed_prekey：7 天 / 1000 次使用
• one-time prekey：7 天 / 1 次使用（用完即弃）

9.8 SM2 TVLA 侧信道验证

SM2 标量乘法已实现 加法掩码（Additive Masking over Z_q），并通过 TVLA 时序验证：

📌 SHA-256 基线对照：未掩码实现在 N=2,000 下 TVLA 全部失败（|t|>10），加法掩码后降至 |t|<4.5，达到 TVLA 通过阈值。

9.9 HMAC-SM3 TVLA 验证

📌 这是首个在纯 JavaScript 环境下通过 TVLA 时序验证的 SM2 / HMAC-SM3 公开实现。

9.10 形式化验证（TLA+）

混合握手协议 Path C-2 已通过 TLA+ 形式化验证（7 条不变量，101,467 状态，0 违例，0 死锁）：

• TypeOK、K1~K5 不变量全部通过
• K3 强形式：直接验证 key[i] ≠ key[j]（密钥间不可区分性）
• 概率漏检 < 2.8×10⁻¹⁰

⚠️ 局限：lossy network 死锁由 TCP 重传绕过（真实协议靠重传）；K3 基于 key=i 构造而非密码级独立采样；EasyCrypt 密码学证明未做。

SM4 当前为查表实现（S-box 查表），存在理论上的缓存侧信道风险。路线图为消除该风险：

📌 当前 SM4 用于通道内数据加密（非密钥协商），缓存侧信道影响远低于协商层；Phase 1 完成后将补齐 TVLA 验证并归档 TSR。