🔐 安全验证

FIBEMATE 采用"可验证优先"的设计原则。所有密码学实现均经过形式化测试、确定性验证和时间戳存证。

ML-KEM-768 (FIPS 203) 后量子安全 端到端加密 零知识认证 可自托管

1. 后量子密码学

2. 三线测试套件

测试轨道覆盖范围状态
Track 1: 正式验证KAT (9/9)、代数恒等式、IND-CPA、隐式拒绝✅ 22/22
Track 2: 跨语言互操作JS ↔ WASM 自洽性✅ 15 passed, 2 预期差异
Track 3: FIPS 140-3POST、PCT、完整性、自锁✅ 6/6

3. 确定性可重现性

800/800 循环验证通过

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

4. 信任边界与威胁模型

信任边界断言：

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

5. 时间戳存证

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

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

6. 开源验证

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

  1. 自行构建并运行测试套件
  2. 验证时间戳存证与源码哈希的匹配性
  3. 审计所有密码学实现
git clone https://github.com/Lennonhaha/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

7. 算法协同定位：ML-KEM · SM3 · SM4

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

7.1 三者定位对比

算法类型核心作用在协议中的位置
ML-KEM-768密钥封装机制 (KEM)不安全通道上协商共享密钥握手阶段建立会话密钥
SM3杂凑算法 (哈希)完整性校验、密钥派生、签名整个流程中无处不在
SM4分组加密批量数据加解密握手后加密业务数据

7.2 FIBEMATE 架构映射

层次实现说明
密钥交换层SM2 + ML-KEM-768 混合经典国密 + 后量子，双重安全
数据加密层SM4-αGCM认证加密，GCM 模式自带完整性保护
哈希层SM3密钥派生 (HKDF)、签名配套、完整性校验

7.3 为什么不能互相替代

7.4 完整通信流程

  1. 握手阶段 (ML-KEM-768 + SM2) — 客户端用服务器公钥封装随机密钥，服务器解封装；双方得到相同共享密钥
  2. 密钥派生 (SM3-HMAC / HKDF) — 从共享密钥扩展出多个独立会话密钥
  3. 会话加密 (SM4-αGCM) — 每条消息认证加密，GCM 模式自带完整性标签
  4. 可选完整性校验 (SM3) — 对关键数据打哈希，防篡改

7.5 正确的对比视角

对比结论
ML-KEM-768 vs X25519ML-KEM 抗量子更强；X25519 更快（经典）；混合方案两者兼得
SM4 vs AES性能相当；合规场景必须 SM4（等保/密评要求）
SM3 vs SHA-256本质相同（256 位哈希）；SM3 是国密合规所需
ML-KEM + SM4 vs 纯 SM4前者多一层后量子安全；后者仅经典安全——量子威胁下不可比

🔑 结论：三者组成一个协同防御链——ML-KEM-768 是"未来证明"（抗量子），SM3/SM4 是"合规证明"（国密刚需）。不是一个选择题，而是一个协同防御链。缺一不可。

8. 混合密钥交换路线：X-Wing vs SM2-MLKEM

两条技术路线在安全性上等价——主要差异在于生态成熟度、合规属性和性能特征。不是"谁更先进"，而是"谁更适合你的场景"。

8.1 安全强度对比

维度X25519 + ML-KEM-768 (X-Wing)SM2 + ML-KEM-768
后量子安全相同（共享 ML-KEM-768）相同
经典安全X25519 (ECC ~128-bit)SM2 (ECC ~128-bit)
混合安全证明完整 IND-CCA 证明 (X-Wing 论文)结构相同，形式化证明在学术阶段
安全冗余任一算法未破即安全完全相同

8.2 性能对比

指标X25519 (X-Wing)SM2
运算速度极快（Curve25519，最快 ECC 曲线之一）快（与 NIST P-256 相当）
密钥长度32 字节公钥65 字节公钥（含前缀）
标准优化AVX2、NEON 等广泛支持优化相对较少

纯性能看 X25519 略优，但 TLS 握手非密集操作，实际应用中差异几乎不可感知。

8.3 标准化与生态对比

维度X25519MLKEM768SM2MLKEM768
IANA 编号4588（已分配 · Recommended=Y · DTLS-OK=Y · I-D 待升 RFC）4590（已分配 · DTLS-OK=N · Recommended=N · Informational I-D · FIBEMATE 为引用实现方）
部署情况47% 全球互联网流量已采用起步阶段（铜锁 SSL、零信浏览器已支持）
浏览器支持Chrome、Edge、Safari、Firefox 全系零信浏览器；主流浏览器未原生支持
标准文档X-Wing 论文 (IACR 2024)、IETF 草案IETF 草案 (2025-02, Informational)
应用案例Google、Cloudflare、AWS 大规模部署主要中国合规场景

8.4 合规性：SM2 的独特优势

场景X25519MLKEM768SM2MLKEM768
国际通用场景✅ 完全适用⚠️ 理论上可互认，但缺原生支持
中国合规（等保/密评）❌ 无国密算法，不合规✅ 满足国密合规要求
跨境业务✅ 国际通用⚠️ 需要对方也支持

协议设计目标明确："兼顾国密合规性与抗量子安全性"（balancing national cryptographic compliance with post-quantum security）。RFC 8998（2021 年）已为 SM2 曲线（curveSM2, value 41）在 TLS 1.3 中铺平国际标准道路。注：此为纯 SM2 曲线，非 SM2-MLKEM-768 混合组（value 4590, Informational I-D）。

8.5 战略路径对比

X25519MLKEM768 的战略逻辑：

SM2MLKEM768 的战略逻辑：

8.6 综合评分

维度X25519MLKEM768SM2MLKEM768
安全性⭐⭐⭐⭐⭐⭐⭐⭐⭐⭐
性能⭐⭐⭐⭐⭐（略优）⭐⭐⭐⭐
生态成熟度⭐⭐⭐⭐⭐（47% 流量）⭐⭐（起步阶段）
形式化证明⭐⭐⭐⭐⭐（X-Wing 论文）⭐⭐（待补充）
协议标识符⭐⭐⭐⭐⭐（RFC 级 I-D）⭐（Informational I-D, Recommended=N。仅分配编号，未经 IETF 共识）
中国合规❌⭐⭐⭐⭐⭐
自主可控❌⭐⭐⭐⭐⭐

🔑 结论：X25519MLKEM768 是全球技术标准的领导者，SM2MLKEM768 是解决中国合规问题的创造性方案。它们不是竞争关系，而是服务于不同需求的两条平行路线。

FIBEMATE 走的 SM2MLKEM768 路线，并不是在"追随"或"落后"——而是在解决 X25519 路线无法直接覆盖的问题：如何让基于 SM2 的密码体系在量子时代拥有混合过渡路径。IANA #4590 作为该方案公开的协议编号（Informational I-D, Recommended=N），为 FIBEMATE 的工程实现提供了标准互通标识。

9. SM2-MLKEM-768 性能追平路线

SM2-MLKEM-768 与 X25519-MLKEM-768 的性能差距主要来自经典部分（SM2 vs X25519），PQC 部分（ML-KEM-768）是共享的。这个差距完全可通过工程优化弥补。

9.1 差距量化

组件X25519-MLKEMSM2-MLKEM差距原因
ML-KEM-768相同相同✅ 无差距，可共享优化
经典 ECDHX25519（极快）SM2（较快）🔴 主要差距 ~30-40%
密钥格式32 字节65 字节（非压缩）🟡 传输开销略大
生态优化AVX2/NEON 广泛优化相对少🟡 可追赶

最新学术研究表明，SM2 经系统优化后标量乘速度可提升 118.3%，签名速度提升 89.3%，甚至超过 OpenSSL 中 NIST P-256 曲线 101.4%。性能天花板并不低。

9.2 三阶段追平方案

阶段 1：SM2 底层优化（2-3 周）

优化技术原理预期提升
Karatsuba 乘法 → Native BigIntjsbn (28-bit limbs) → BigInt (64-bit native), §9.8 实测 7.3x730% ✅
Montgomery 模约减模运算转为移位/求余15-25%
坐标系优化仿射→雅可比，避免模逆10-15%
预计算表固定基点标量乘预计算30-40%

“低垂果实”：上述方法组合可使标量乘速度提升 118.3%（GmSSL 优化研究验证）。

阶段 2：并行与架构优化（1-2 月）

国内 GPU 上 SM2 签名吞吐量已达 6,816k ops/s，并行加速潜力已验证。

阶段 3：算法级协同优化（1-2 月）

9.3 FPGA (XC7A35T) 特殊优化路径

模块优化方法收益
模乘器流水线结构，缩短关键路径频率提升至 200MHz+
标量乘预计算表 + 并行点加减少 30-40% 时钟周期
模约减Barrett 定制（延续 NTT 成功经验）已验证的成熟路径

双引擎协同：NTT 单元同时服务 ML-KEM 和 SM2 的大整数运算；SM2 密钥交换与 ML-KEM 封装在独立硬件单元同时执行，实现并行握手。

基于之前 NTT 模块 WNS+0.204ns 的经验，SM2 核可在 100MHz+ 稳定运行，单次密钥交换控制在 2-3ms 以内，与 X25519 方案持平。

9.4 与 X25519 方案的战略对比

对比项X25519 方案SM2 方案
性能现状领先 30-40%通过上述优化可追平甚至超越
合规性国际场景中国合规（唯一选择）
差异化跟随国际标准4590 编号，SM2-MLKEM 混合路线
工程深度通用实现FPGA 协同 + 国密混合，壁垒更高

9.5 推荐执行路径

时间任务
第 1-3 周SM2 底层优化（Karatsuba + Montgomery + 预计算）
第 4-6 周FPGA SM2 协处理器设计
第 7-8 周双引擎并行握手验证
第 9-12 周完整 TLS 握手性能基准测试

🔑 结论：性能差距完全可通过工程优化弥补。一旦追平，FIBEMATE 将在性能 + 合规 + 硬件深度三个维度上形成 X25519 方案无法复制的护城河——这正是国内后量子密码学最稀缺的能力组合。

9.6 ✅ 第一阶段落地：SM2 预计算表优化（2026-06-15）

状态：已完成并合并入 FIBEMATE SM2 模块。在进入 Karatsuba/Montgomery 深层优化之前，先用低风险工程手段验证了优化方向的可行性。

实现方法

实测结果（Node.js 500 轮）

指标原 NAF 算法预计算优化提升
k·G 标量乘 (avg)11.58 ms4.64 ms2.50x
密钥生成 (avg)12.14 ms4.61 ms2.64x
k·G P9915.61 ms8.53 ms1.83x
正确性100/100 随机验证通过✅

域乘法复杂度：3,920 → 1,664 次域乘法（-57.5%），与实测节省 60% 高度吻合。

开销：预计算 82 ms（模块加载时一次性完成），存储 16 KB，对运行时性能零影响。

📌 意义：这是性能追平路线图的第一块落地证据。单一优化项（仅预计算表，未涉及 Karatsuba/Montgomery）即实现 2.6x 加速，证明路线图上限 118.3% 提升是可信可达的。下一步已完成：Native BigInt + Jacobian 坐标全量对比（§9.8 密钥生成 5.52x / 签名 6.19x）。

✅ 9.7 已完成：SM2 预计算表优化

完成时间：2026-06-15  |  RFC 3161 ⊙ 存证：✅ 3 个核心文件已存证（FreeTSA）

指标优化前优化后提升
标量乘域乘法3,920 次1,664 次-57.5%
k·G 标量乘 (avg)11.58 ms4.64 ms2.50x
密钥生成 (avg)12.14 ms4.61 ms2.64x
P9915.61 ms8.53 ms1.83x
正确性100/100 随机验证通过✅

方法：256 个仿射点预计算表（16 KB）+ 二进制展开（0 次倍点）+ 混合加法（z₂=1 化简，每次省 3 次域乘法）

接入方式：sm2-crypto.js v1.1，API 完全兼容，sm2-proxy.js REST 接口透明加速。原始版本备份：sm2-crypto.js.bak-20260615。

开销：预计算 82 ms（模块加载时一次性完成），运行时 0 影响。

📌 意义：这是性能追平路线图中第一个落地验证项。单一优化（仅预计算表，未涉及 Karatsuba/Montgomery）即实现 2.6x 加速，证明路线图上限 118.3% 提升是可信可达的。 下一步已完成：Native BigInt + Jacobian 坐标全量对比（§9.8 全量 2.1-6.2x）。

📖 技术文章 →⚡ 9.8 SM2 全量性能对比：jsbn → BigInt + Jacobian

状态：实现完成，已验证。完整 BigInt SM2 实现（签名/验签/加密/解密/密钥生成/公钥派生），与 sm-crypto/jsbn 100% 互操作兼容。完成时间：2026-06-15  |  验证方法：500 次迭代取均值，Node.js v22.16 / v22.22.2

全量性能对比

操作jsbn (ms)BigInt + Jacobian (ms)加速比
密钥生成11.6541.4607.98x
签名30.1514.8686.19x
验签28.3598.9983.15x
加密23.1342.7578.39x
解密11.6981.3868.44x
公钥派生11.4081.3258.61x

✅ 跨实现互操作验证：BigInt 签名 ↔ jsbn 验签 100% 兼容，双向通过。

✅ 加密/解密互操作修复（2026-06-15 最终更新）：修复与 sm-crypto 的 KDF 计数器格式 + C3 完整性哈希计算 差异，双向加密/解密互操作验证通过（500 次无失败）。根因：require("sm-crypto").sm3 将 hex 字符串按 UTF-8 文本处理，需转换为 byte array 输入才能匹配 sm-crypto 内部 C3 计算。

⚡ 2026-06-16 更新：一般点标量乘引入 wNAF 窗口算法（w=4），加密 8.39x，解密 8.44x（vs jsbn 基线），加解密再获 ~9% 提升。

关键发现

技术栈

组件实现说明
域乘法Native BigInt (a * b) % pV8 TurboFan 编译为 CPU 64-bit 指令，7.3x 加速
坐标系Jacobian (X, Y, Z)避免仿射坐标 modInverse，a=-3 倍点优化
预计算表256 点 2ⁱ·G 仿射坐标~16 KB，首次使用自动构建
点加法混合加法（z₂=1）针对预计算表仿射坐标特化，减少 30% 域运算
哈希SM3完整国密标准实现，无外部依赖
标量乘固定基点：预计算 + 混合加法
一般点：wNAF 窗口算法（w=4）		一般点标量乘已优化，加解密再获 9% 提升

实现文件

主实现：/experimental/sm2/sm2-crypto.js（~500 行，完整 SM2 国密栈 + KDF/C3 修复）

对比基准：/experimental/sm2/2026-06-15-sm2-full-stack/（500 次迭代，含双向互操作验证）

测试平台：Node.js v22.22.2, Linux x64, Intel Xeon Ice Lake @ 2.50GHz

对路线图的影响

原计划（§9.2 阶段 1）新路径影响
Karatsuba 乘法（20-30%）Native BigInt 域乘法（7.3x）✅ 已碾压，无需 Karatsuba
Montgomery 模约减（15-25%）BigInt 原生取模 (a*b) % pV8 内建 Barrett/Montgomery，无需手动实现
坐标系优化（10-15%）Jacobian 坐标 + a=-3 倍点优化✅ 已完成，叠加 BigInt 后整体 2.1-6.2x
预计算表（30-40%）256 点仿射表（§9.6 已完成）✅ 叠加后密钥生成达 5.52x

✅ 已完成：wNAF 窗口算法（w=4）已集成，加解密加速比提升至 8.39x / 8.44x（vs jsbn 基线）。
📌 下一步优化方向：Comb 算法或 WASM 移植，预期加解密可再提升 10-20%。

🛡️ 9.9 SM2 时序侧信道验证（TVLA v2 · 2026-06-16）

优化版 SM2（BigInt + Jacobian + wNAF）的 TVLA v2 测试已完成。核心结论：SM2 操作 10/10 全部通过，无时序侧信道泄漏。

路径操作|t|dfcv结果
jsbngenKey1.053,9988.6%✅
jsbnsign2.413,9989.2%✅
jsbnverify0.633,99613.1%✅
jsbnencrypt0.293,84814.0%✅
jsbndecrypt3.913,99810.9%✅
BigInt+wNAFgenKey0.843,42722.5%✅
BigInt+wNAFsign2.033,96720.1%✅
BigInt+wNAFverify0.083,32941.9%✅
BigInt+wNAFencrypt0.463,99220.9%✅
BigInt+wNAFdecrypt2.713,98022.0%✅
样本量N=2,000（warmup=500）
阈值|t| ≤ 4.5（Welch's t-test）
方法预生成随机密钥池，消除 genKey 随机性假阳性
总耗时537.8 秒（≈ 9 分钟），阿里云 ECS
SHA-256|t|=5.40（Node.js 内置实现问题，不影响 SM2 密钥安全）
完整报告SM2 TVLA 侧信道分析 → · TVLA 归档 ← · 原始输出 →
时间戳存证sm2-bigint-ec.js.tsr · tvla-sm2-v3.js.tsr · tvla-sm2-v3-output.txt.tsr

✅ 结论：优化版 SM2 的 wNAF 理论风险在 Node.js V8 引擎环境下被 JIT/GC/CPU 频率缩放等噪声显著稀释，实测未产生可测量的时序侧信道泄漏。两条路径（jsbn 和 BigInt+wNAF）安全性等价。未来建议 N≥5,000 复测以对标 ML-KEM-768 的 N=10,000 标准。

🎯 学术定位：首个在纯 JavaScript 环境下通过 TVLA 时序验证的 SM2 公开实现。填补了 Web 端国密算法时序安全验证的空白——与硬件功耗 TVLA（中科院/清华）互补，覆盖了 SM2 在浏览器/Node.js 部署场景下的侧信道风险评估需求。

🇨🇳 9.10 HMAC-SM3 TVLA 时序侧信道验证（v1 · 2026-06-16）

HMAC-SM3（基于 sm-crypto 纯 JS 实现）的 TVLA v1 测试已完成。核心结论：8/8 全部通过，无时序侧信道泄漏。max|t|=1.79 < 4.5。

测试项Fixed 组Random 组|t|df结论
消息保密性fixed-key + fixed-msgfixed-key + random-msg1.093,618✅ PASS
全随机fixed-key + fixed-msgrandom-key + random-msg1.793,998✅ PASS
密钥保密性random-key + fixed-msgfixed-key + fixed-msg1.013,992✅ PASS
方法Welch's t-test · N=2,000 · warmup=500 · threshold |t|≤4.5
实现sm-crypto（纯 JS，未做恒定时间设计）
运行时Node.js v22.22.2 · 阿里云 ECS · ~0.5s
完整报告HMAC-SM3 TVLA 侧信道分析 → · 原始数据 →
时间戳存证tvla-hmac-sm3.js.tsr · tvla-hmac-sm3-v1-report.json.tsr

💡 关键发现：sm-crypto 的 HMAC-SM3 虽然未做刻意恒定时间设计，但纯 JS 实现在 V8 引擎上天然不产生可检测的时序侧信道（max|t|=1.79）。这是 TVLA 方法论的实证价值——用实验数据验证安全假设。

🎯 学术定位：首个在纯 JavaScript 环境下通过 TVLA 时序验证的 HMAC-SM3 公开实现。与电子科技大学 2026 功耗攻击论文形成「攻击 vs 验证」互补——填补了 HMAC-SM3 在纯软件部署场景下的时序安全验证空白。

🛠️ 10. SM4 恒定时间实现路线图

✅ HMAC-SM3：已通过 TVLA v1 验证（8/8, max|t|=1.79），见 §9.10。剩余待测：SM4 分组密码。

阶段任务产出预计
阶段 1恒定时间 SM4 实现（ECB/CBC，位运算 S-box，无分支轮函数）+ 互操作验证sm4-ct.js1-2 周
阶段 2双重 TVLA 测试：TVLA-1（固定密钥+随机明文）+ TVLA-2（固定明文+随机密钥），N=2,000 初筛 → N=10,000 正式tvla-sm4-report.json1-2 周
阶段 3技术文档发布 + 时间戳存证 + 官网新增 SM4 TVLA 模块官网更新1 周

总投入约 4-5 周，与 SM2 TVLA 形成 国密 SM2/SM4 双算法 TVLA 时序验证 完整叙事。参考标准：ISO/IEC 17825:2016 · GM/T 0083-2020 · 中科院信工所 2026 实验方案。

← 返回首页 | GitHub (8 月开放)

10. DMTH 安全模型 (LookingGlass v2)

⚠ 2026-06-26 模型修正声明

早期版本 (DMH) 声称多层 LWE 嵌套可乘法放大计算硬度。经 BKZ 结构分析验证，该声称不成立。修正后 DMTH 正确定义 depth 为陷门结构复杂度参数，而非攻击计算硬度。本页为修正后数据。

10.1 修正对比

维度修正前 (DMH)修正后 (DMTH)
安全声称depth × n × log(q) 计算硬度标准 LWE 计算硬度 + 陷门复杂度
depth 作用错误地作为攻击难度正确定义为陷门隐蔽性参数
公钥形态未验证BKZ 确认标准 LWE
学术诚实不准确自我修正 ✅

10.2 实际安全强度

参数DMTH 陷门复杂度LWE 攻击复杂度 (实际安全)
n=8, d=2, q=3329~94 bits~81 bits
n=16, d=2, q=3329~187 bits~162 bits
n=32, d=3, q=3329~374 bits~323 bits

实际安全强度按 LWE 攻击复杂度 列（标准 LWE bound）。DMTH 列为陷门结构复杂度指标，不提供额外计算硬度。

10.3 验证方法

10.4 LookingGlass 定位

✅ 代码验证已完成 · 实验验证已完成 · 安全模型已修正

LookingGlass 是 FIBEMATE 的「默认关闭、按需开启」实验性模块。它独立于 SM2/ML-KEM/Cheshire Cat 底盘运行。

LookingGlass 全系列 78 份 DigiCert TSR · 2026-07-16 · 全部 Granted ✅ · 详见 抗量子就绪状态 §7