systemslibrarian/crypto-lab-threshold-mldsa

# crypto-lab-threshold-mldsa — Threshold ML-DSA 签名 ML-DSA（NIST FIPS 204，标准化的后量子数字签名算法）门限签名协议的浏览器端教育演示。该应用模拟了受 Trilithium 启发的简化双方签名流程，其中服务器端（Server）和手机端（Phone）协作生成签名，且该签名仍能通过标准的 ML-DSA 验证器验证。 技术栈：Vite + TypeScript strict + 原生 CSS + `@noble/post-quantum/ml-dsa`。无后端。 ## 它是什么 该代码库演示了后量子密码学中关于门限签名的核心问题： - 多方能否协作生成单个有效的 ML-DSA 签名？ - 验证器能否保持不变，并在标准的 FIPS 204 验证下依然接受该签名？ - 为什么这比门限 Schnorr 或门限 BLS 更困难？ 该演示通过基于当前研究方向的具有教育意义的双方模拟回答了这些问题： - **Trilithium** — Dufka, Kravtsenko, Laud, Snetkov, ePrint 2025/675 - **Quorus** — Borin 等人, ePrint 2025/1163 - **TOPCOAT** — 2024 年双方 HighBits 压缩方法 - **Dufka–Kravtsenko 可识别中止** — ePrint 2025/871 - **del Pino–Prest 揭示型 TRaccoon** — ePrint 2025/849 - **THED** — ePrint 2026/638 - **Threshold Raccoon** — Saarinen, EUROCRYPT 2024 实时 UI 包含五个展示模块： 1. 为什么门限 ML-DSA 比经典的门限签名更难 2. Trilithium 风格的分步协议演示 3. 具有拒绝即重启行为的交互式双方签名 4. 2024–2026 年门限 ML-DSA 研究领域的对比表 5. 后量子多方签名的现实应用场景 ## 哪些是真实的，哪些是模拟的 一个密码学演示只有精确界定自身的局限才能赢得信任。本演示划定了一条明确的界限： **真实的（标准 FIPS 204）：** - 密钥生成、签名和验证均使用 `@noble/post-quantum` 的 ML-DSA-65。 - 公钥和每个生成的签名都是真实的，并且能在**未经修改**的标准验证器下通过验证。 - 所有的随机性均来自 Web Crypto CSPRNG —— 在 `src/` 中的任何地方都没有使用 `Math.random`。 - 加性秘密共享是真实的：每一份共享自身都是均匀分布的，不会透露关于秘密的任何信息。 **模拟的（用于教学）：** - 逐轮的 nonce / `w₁` / 挑战 / `z` 交换过程是*编排好的虚拟流程*。它们展示了协议的形态，但并不实际生成签名。 - “安全范数检查”会以明文形式显示组合值，而不是运行真正的 MPC。 - 拒绝情况是被人为注入的，以便您观察拒绝即重启的行为。 - **为了实际进行签名，演示会在同一位置重构完整的私钥**，并调用标准签名器。因此，它**并未**实现真正的密钥不可重构性——这是生产级门限方案必须提供的核心属性。 总而言之：ML-DSA 的数学原理是真实的，输出的是有效的 FIPS 204 签名；而*分布式信任*属性只是被演示出来，并未被真正强制执行。弥合这一差距正是本实验室存在的意义——解释这个开放的研究问题。 ## 何时使用 在以下情况中，您可以使用此演示： - 理解为什么门限格密码签名比门限 Schnorr 或 BLS 更复杂 - 在纯浏览器环境中研究双方 ML-DSA 协议的结构 - 查看待应用于 ML-DSA 风格密钥组件的加性秘密共享 - 比较通信轮次、字节成本以及与独立签名相比的重启行为 - 向工程师、学生、审计员或安全团队解释门限后量子签名 - 探索用于根 CA、验证者网络、恢复流程和企业审批的未来设计理念 **请勿**将此代码库用于生产环境的签名系统、HSM 部署或对合规性敏感的基础设施。 ## 在线演示 GitHub Pages 目标地址： - https://systemslibrarian.github.io/crypto-lab-threshold-mldsa/ 本地开发： ``` npm install npm run dev # start the Vite dev server npm run build # typecheck (tsc) + production build npm run verify # run the verification suite (exits non-zero on failure) ``` `npm run verify` 是项目的测试门槛：它检查加性共享、分布式密钥生成、双方签名、标准验证器兼容性、篡改拒绝、单方阻断、禁用 `Math.random` 规则以及诚实性披露。`build` 和 `verify` 都会在每次推送和 Pull Request 时通过 GitHub Actions (`.github/workflows/ci.yml`) 运行。 ## 可能出现的问题 门限 ML-DSA 仍然是一个活跃的研究领域，目前还存在几个实际问题： - **尚无 NIST 门限标准。** 验证器兼容性已在研究论文中实现，但门限协议本身尚未标准化。 - **拒绝采样增加了协调成本。** 如果签名尝试被拒绝，所有各方都必须重新生成新的随机性。 - **通信开销至关重要。** 即使是高效的双端设计，其交换的数据量也远超独立签名。 - **恶意环境下的安全性很难保证。** 半诚实（Semi-honest）的近似方案不足以应对现实世界中的对手。 - **非线性组件处理棘手。** HighBits、LowBits、MakeHint 和范数检查需要谨慎的 MPC 处理。 - **实现陷阱依然存在。** 时序泄漏、重放处理、消息绑定、转录一致性以及中止问责制都至关重要。 - **本演示简化了 MPC 内部原理。** 它的目的是教授协议的形态和兼容性目标，而不是作为一项经过强化的实现。 ## 现实用例 如果门限 ML-DSA 走向成熟并实现标准化，可能的部署目标包括： - 跨越多个 HSM 或组织的**后量子根 CA 保护** - 消除单节点妥协风险的**区块链验证者签名** - 采用 t-of-n 控制的**政府和企业审批工作流** - 针对长期用户凭据的**社交恢复和紧急访问** - **分布式随机信标**和其他集体授权系统 目前，生产系统通常使用经典的门限方案（如 FROST 或门限 ECDSA），同时关注后量子迁移计划。 合理的预测时间表如下： - **2026–2027：** 研究整合与密码分析 - **2027–2028：** 可能的门限标准草案或配置文件 - **2028–2030：** 如果该领域趋于稳定，将进行早期生产部署 ## 仓库描述 ## 建议的 GitHub Topics ``` cryptography post-quantum ml-dsa threshold-signatures distributed-signing multi-party-computation trilithium lattice-cryptography fips-204 mpc browser-demo educational typescript vite ```

标签：TypeScript, Web前端, 后量子密码, 安全插件, 密码学, 手动系统调用, 教学演示, 自动化攻击, 门限签名