阅读声明与边界本文讨论论文 Efficient Threshold ML-DSA。文章的重点不是逐字复述论文而是解释三个问题为什么标准 ML-DSA 很难直接门限化论文如何利用 short replicated secret sharing、optimized rejection sampling 与 RSSRecover 构造一个面向小规模参与方的 Threshold ML-DSA论文的安全、参数、benchmark 与 deployment claim 能支持到什么程度。需要先明确几个边界。第一本文中的 ML-DSA 背景来自 FIPS 204 与 CRYSTALS-Dilithium 的设计框架Efficient Threshold ML-DSA 的作者并没有重新发明 ML-DSA也没有提出 AI 方法。第二论文给出的实现属于 academic proof-of-concept。local、LAN 和 WAN benchmark 可以说明 small-party setting 的研究可行性但不能直接推出 production-ready、side-channel safe 或任意网络环境下都能达到同样性能。第三本文会区分“论文明确给出的事实”和“为了帮助理解而给出的直觉”。对于尚未逐项核验的概率公式、参数口径和 related-work novelty统一保留在文末的 TODO_VERIFY 中。为什么 Threshold ML-DSA 是一个真实问题ML-DSA 解决的是后量子数字签名问题给定一把签名私钥签名者可以生成签名任何人都能使用公钥验证。它回答的是在量子攻击背景下如何得到一个标准化、可实现、可验证的格签名但标准签名仍然保留一个传统问题私钥是单点信任根。只要完整私钥被窃取、滥用或错误备份攻击者就可以独立签名。Threshold signature 希望把 signing authority 分散给多个参与方。一个典型的-of-系统要求任意至少个参与方可以合作签名少于个参与方即使合谋也不能生成有效签名最终验证者最好不需要知道内部参与方、share 结构和交互 transcript。这类技术可以服务于密钥托管、机构级签名、分布式 CA、钱包和高价值服务认证。但“把 ML-DSA 私钥拆开”并不等于“得到 Threshold ML-DSA”。真正困难的是ML-DSA 的签名响应本身包含秘密相关偏移而且签名算法依赖 abort-and-retry。因此Threshold ML-DSA 要解决的不是底层 MLWE 困难度增强而是如何把 signing authority 分散给多方同时保持 ML-DSA 的响应分布、安全证明与最终验证格式ML-DSA 的 Fiat-Shamir-with-aborts 难在哪里3.1 从 Schnorr 到格上的响应Schnorr 签名可以用 commit–challenge–response 理解其中是秘密是新鲜随机量。格签名采用类似骨架区别在于不只是一个模群标量而是短向量或多项式向量。其范数和分布直接影响签名大小、验证正确性与信息泄漏。3.2 Secret-dependent bias核心响应为如果直接输出所有这样的其分布相当于的分布被秘密相关量平移。不同秘密可能诱导不同的输出偏差。Fiat-Shamir with Aborts 的作用不是简单地“多试几次”而是通过拒绝不合格样本让最终公开的 accepted response 更接近一个不显著依赖秘密的目标分布。单方签名时失败候选值只在本地丢弃外界看不到它们。门限签名时每个参与方都形成类似的局部候选。如果各方为了共同判断是否成功而公开 rejected partial candidate就可能暴露 share 的统计信息如果把所有条件都放进通用 MPC又会带来很重的通信与计算。这就是本文的主要切入点多方必须协作完成 abort-based signature但被拒绝的局部候选值不能泄漏。本文的总体方案论文的整体构造可以压缩为下面一条流程Short RSS / Keygen↓ShareSign1commit↓ShareSign2reveal↓ShareSign3challenge RSSRecover per-party HRej↓Combine聚合 response global rejection hint↓ML-DSA-style Verify其中每个组件解决一个不同问题Short replicated secret sharing让各方需要处理的局部秘密保持短Commit–reveal防止恶意参与方看到其他人的 commitment 后再自适应选择自己的值RSSRecover把所有 base secret pieces 分配给当前 active parties并控制最大局部负载HRej在公开局部响应前隐藏引入的秘密相关偏移Global rejection保证最终聚合签名满足 ML-DSA 的范数、rounding 和 hint 边界Parallel protocol instances以通信和计算换取更高的成功概率Combine/Verify compatibility最终签名仍是风格外部 verifier 不需要 threshold transcript。最值得注意的是本文没有用单一技巧解决全部问题而是把 share size、rejection geometry、参数选择、成功率和通信量连接成一个闭环。Table 1如何理解本文与前人的比较Table 1 的主要价值是定位本文而不是给出一个无条件的“排行榜”。比较 Threshold signature 时至少要同时考虑honest-majority 还是 dishonest-majority是否需要 trusted dealer、trusted setup 或 correlated randomnessonline/offline round 数是否输出标准兼容签名通信量是 per party 还是 total报告的是一次 attempt还是一次成功签名的平均成本实现语言、硬件、网络和代码成熟度是否有公开 artifact。因此Table 1 中的 generic MPC、Trilithium、Bienstock et al. 与本文并非在所有维度完全同口径。更稳妥的理解是本文试图占据这样一个位置不使用通用 MPC 把整个 ML-DSA 电路黑盒化而是针对 FSwA 的结构设计 specialized protocol同时保留标准 ML-DSA-style verification。“first practical”是论文作者的 novelty claim。它可以作为论文定位来介绍但若要写成独立的绝对结论仍应完整核验 concurrent work 和各方案的模型边界。Figure 1 / Figure 2安全模型和 correctness with aborts6.1 Figure 1TS-UF普通签名不可伪造性通常允许攻击者访问完整签名 oracle然后要求它对新消息产生有效伪造。门限场景更复杂。攻击者还可能腐化少于门限的参与方获得这些参与方的 secret shares参与或观察多轮 signing transcript控制部分协议消息和调度。因此TS-UF 不只是“最终 Verify 通过与否”而是约束攻击者在拥有部分 shares 和交互视图时仍不能产生新签名。6.2 Figure 2Correctness with Aborts传统正确性容易被理解为诚实签名一定输出有效签名。但对 FSwA 类方案更准确的语义是诚实执行可能合法输出一旦输出非该签名必须通过 Verify非 abort 的概率至少达到某个。这就是 p-termination。它把“安全机制导致的合法拒绝”与“实现出错”区分开。这一区分非常重要因为后文的参数正是用来提高一次完整执行中至少出现一个成功候选的概率而不是让单个 HRej 永远不 abort。Figure 3 / Figure 4从 Rej 到 HRej7.1 Figure 3Rej 与 Ideal可以把 Figure 3 理解为一个证明桥梁。真实协议中的局部响应依赖秘密偏移理想世界希望响应来自一个与无关的目标分布。论文定义 Rej 与 Ideal并使用 smooth Rényi divergence 控制两者的区别。这里需要注意Ideal 不是协议真实运行的算法。它是 hybrid proof 中的理想分布用来证明攻击者看到的 transcript 可以逐步替换为与局部秘密无关的视图。7.2 为什么使用 smooth Rényi divergence总变差距离当然也能衡量分布接近程度但本文要处理多个 parties、多个签名查询和多个并行实例。Rényi divergence 的组合性质更适合进行多次分布替换的损失记账。“smooth”表示允许先移除一个总概率至多为的坏集合再在剩余点上控制 likelihood ratio。直觉上它允许证明忽略极端尾部事件同时严格记录其概率损失。7.3 Figure 4HRejHRej 使用 imbalanced hyperball。其 response 被分成两部分并对第一部分引入参数形成不对称几何。这种设计与最终签名结构有关显式输出的是 response 的第一部分第二部分的影响可在 Combine 中通过和 hint 间接恢复。因此不同 block 的接受域不必完全对称。HRej 的参数链是Lemma 3.1 利用这些条件把 HRej 的真实分布与目标分布联系起来。它不是最终不可伪造性证明而是 Appendix G 中 Rej-to-Ideal 替换所需的局部工具。Short Replicated Secret Sharing本文使用的 RSS 不是 Shamir sharing。对所有满足的子集采样短 base secret并定义party持有所有满足的。这个访问结构有一个直接性质任意大小为的 active set 与任意这样的必有交集。因此每个 base secret piece 至少被一个 active party 持有。但“能恢复”还不够。签名时还要给每个 base secret piece 指定一个负责方使它被恰好计入一次。若某个 party 被分配过多 pieces则可能变大进而放大降低 HRej 的接受率。因此 RSSRecover 的优化目标不是密码学正确性的附属细节而是把 secret-sharing access structure 与 rejection efficiency 连接起来。Appendix B 将负载平衡问题与 max-flow / B-matching 联系起来对的实现论文利用预计算的 optimal partitions 和对称置换避免在线运行通用求解器。Table 2哪些是 ML-DSA 参数哪些是 threshold 新参数Table 2 将参数分成两层。9.1 标准 ML-DSA 参数例如它们决定环、矩阵维度、challenge 稀疏度、秘密与响应范数、rounding 尺度和 hint weight。9.2 Threshold 新参数并行 protocol instances 数量HRej 的不平衡系数随机掩码分布半径目标响应分布半径rejection / Rényi 因子。其中这些参数不能独立选择。其依赖关系大致为N,T 与 RSSRecover→ partial secret size→ B→ r,r′,ν→ M→ local acceptance→ K→ communication/runtime因此参数表不是简单的“经验调参”而是正确性、分布证明和性能共同约束的结果。Figure 5Keygen / RSSFigure 5 同时定义 RSS 和门限 Keygen。首先采样 matrix seed然后通过 RSS 生成 aggregate secret及每个 party 的 replicated shares。论文以紧凑形式形成 public relation接着执行 Power2Round并计算最终这里最重要的是 public sideverification key 仍保持 ML-DSA-style 结构。门限化主要发生在 secret side 与 signing workflow而不是要求所有外部 verifier 理解新的门限格式。Figure 5 为简化叙述默认存在 trusted dealer。Appendix D 的 DKG 再处理如何去掉这一假设。Figure 6三轮 Signing Protocol11.1 ShareSign1Commitparty采样计算局部 commitment再发送这一轮的目的不是节省带宽而是防 rushing恶意 party 不能先观察其他人的再选择一个有利的。11.2 ShareSign2Reveal 与状态绑定各方 reveal并检查party 是否属于 active set对应 state 是否存在reveal 是否匹配 commitmentactive set、message 和 previous messages 是否一致。这些绑定不是形式主义。缺失它们可能导致 replay、cross-session confusion、active-set mismatch 或 state reuse。11.3 ShareSign3Challenge、RSSRecover 与 HRej各方先聚合计算随后调用 RSSRecover 得到 partition并构造最后运行若返回party abort否则只输出。这一步是 thresholdization 的核心局部 response 在公开前先完成 rejection从而避免公开 secret-dependent rejected candidate。Figure 7Combine / Verify 与 ML-DSA 格式兼容12.1 CombineCombine 重新聚合、重建 challenge并计算随后定义这个把未显式输出的 response 部分、公钥压缩误差和验证所需 correction 统一封装起来。然后生成 hintCombine 检查通过后输出12.2 VerifyVerifier 只使用、消息和 signature计算再检查 challenge hash、response norm 和 hint weight。这正是论文 compatibility claim 的核心verifier 不知道 active setverifier 不知道 secret sharesverifier 不需要 ShareSign transcriptthreshold protocol 输出被压回 ML-DSA-style signature。需要注意这不意味着 threshold protocol 本身已经成为 FIPS 204 的一部分兼容的是最终验证对象和验证逻辑。Per-Party Rejection 与 Global Rejection两层 rejection 都会产生 abort但作用不同。层 位置 主要目标Per-party rejection ShareSign3 / HRej 隐藏局部Global rejection Combine 保证最终、、满足 ML-DSA 边界如果只保留 global rejection会发生什么各方已经把局部 candidate 发给 Combine。即使最终签名被拒绝局部 secret-dependent 信息可能已经暴露。因此 global rejection 不能替代 per-party rejection。反过来只做 per-party HRej 也不够。局部输出分布可能已经安全但聚合后的 response、rounding error 或 hint weight 仍可能超出标准 ML-DSA 的验证边界。所以本文的 two-stage rejection 是职责分离第一层服务 transcript hiding第二层服务 correctness、signature bounds 和 compatibility。14. Correctness 与 Security 的直觉14.1 Lemma 3.1 的位置Lemma 3.1 不是最终不可伪造性定理。它做的是局部工作对建立范数上界在满足相应条件时给出 HRej 真实分布与目标分布之间的 smooth Rényi bound。因此其逻辑链是14.2 Theorem 3.1p-terminationTheorem 3.1 关心诚实执行是否能以足够概率输出有效签名。成功需要同时满足所有必要 parties 的 local HRej 通过global checks 通过个并行候选中至少有一个完整成功HighBits collision 等坏事件未发生。因此是 success amplification它用更多通信和计算换取更低的在线重试概率。14.3 Theorem 3.2 与 Game 0–13安全证明的高层路线是从真实 TS-UF game 出发处理 commitments 和 random-oracle programming把 response 的采样顺序变成更适合证明的形式加入范数界为 Lemma 3.1 创造条件用 MLWE-type hybrids 隐藏 rejected branch 或 public-key relation用 smooth Rényi 将 Rej 替换为 Ideal最终把 threshold forgery 转交给 ML-DSA unforgeability challenger。因此本文的安全不能简化为“只依赖 MLWE”。更准确的表述是证明结合 ML-DSA UF、MLWE-type assumptions、Random Oracle Model、commitment/challenge programming 和 Rényi divergence。A Posteriori Key Sharing 与 DKG15.1 A Posteriori Key Sharing普通 threshold Keygen 是先生成 shares再得到新的 key。A posteriori sharing 处理相反问题已经存在一个 ML-DSA signing key希望在不改变 verification key 的情况下把它拆成 threshold shares。若固定 secret 为所有合法 share tuples 满足zero-sharing lattice 为合法 shares 则形成一个 coset难点是不能随便选个短 shares再让最后一个承担全部差值因为最后一个 share 可能过大。论文因此考虑在 coset 上进行离散高斯式采样。但 conditioned short shares 会提供关于原 secret 的 noisy hints。论文以 generalized hint-MLWE 建模这一泄漏。对 Gaussian secret归约较清晰实际 ML-DSA secret distribution 则带有额外 heuristic caveat。因此公开文章中最安全的结论是论文给出一种保留原 verification key 的 a posteriori sharing 方法但其安全分析比普通 Keygen 更微妙并包含 hint-MLWE 与参数启发式边界。15.2 DKGFigure 5 默认存在 trusted dealer。Appendix D 的 DKG 试图让 parties 共同生成 key而不由单一实体掌握完整 secret。高层流程包括针对 share group 建立 shared secretcommit-reveal 全局 randomnessgroup leader 从 shared secret 和 randomness 派生局部 secret计算并 commit-reveal partial public keys聚合最终。DKG 与 a posteriori sharing 解决不同生命周期问题DKG从零生成新 threshold keyA posteriori sharing拆分已有 key 并尽量保持原 verification key。论文提供了 DKG 设计与分布论证但 robustness、identifiable abort、secure-channel assumptions 和 benchmark coverage 仍应谨慎核验。Benchmark哪些 claim 有数据支撑哪些不能外推16.1 有数据支撑的内容论文实现使用 Go、CIRCL 和 libp2p测试 ML-DSA-44/65/87 的若干 local settings并对 ML-DSA-44 进行了 LAN/WAN 测试。代表性的 ML-DSA-44 local 数据显示标准 Verify 的耗时较稳定SignCombine 随、和通信负载显著变化某些setting 可能比更便宜因为 RSSRecover aggregation overhead 消失。LAN 测试报告了 latency 和 TCP packet countWAN 测试覆盖 Taipei leader 与若干 AWS region 组合。特定配置下论文报告的 signing latency 低于一秒。这些结果支持在论文给定硬件、参数和网络拓扑下small-party Threshold ML-DSA 具有研究层面的可行性。16.2 不能外推的内容论文数据不能自动证明任意 WAN 环境都低于一秒所有setting 都实用实现 constant-time 或 side-channel safeDKG 与 a posteriori sharing 已获得同样完整 benchmark与其他方案的所有数据完全同口径artifact 可以直接用于生产部署。尤其需要区分per party 与 total communicationper attempt 与 per successful signatureoffline 与 onlinelocal CPU time 与 network-inclusive latency是否包含 abort retry、serialization 和 preprocessing。论文自己的 artifact statement 将实现定位为 academic proof-of-concept这一边界应被保留。Related WorkGeneric MPC、Trilithium、Bienstock et al. 与本文17.1 Generic MPC最直接的思路是把整个 ML-DSA signing algorithm 放进通用 MPC。优点是抽象清晰缺点是 norm checks、rounding、hint、hash 和 rejection 都可能造成高昂代价。本文选择针对 FSwA 结构做 specialized design。17.2 TrilithiumTrilithium 是 Threshold Dilithium/ML-DSA 路线的重要前作。比较时需要特别检查是否使用 trusted correlated randomness、offline preprocessing以及报告的是在线开销还是整体开销。17.3 Bienstock et al.论文将本文与 Bienstock et al. 的工作比较但二者的安全模型、实现环境、honest-majority assumptions、correlated randomness 和复现条件可能不同。若原实现不可复现或硬件不同数字只能用于有限定位。17.4 Raccoon、T-Raccoon、Ringtail这些方案也属于 lattice-based threshold signature 比较对象但它们不一定以标准 ML-DSA verification compatibility 为核心目标。因此比较必须同时看签名格式、密钥格式、security model 和部署要求而不是只看毫秒或字节数。总之related-work 表格最适合回答“本文试图解决什么”不适合直接回答“谁在所有方面最好”。最容易误读的点Threshold ML-DSA 不会提高 MLWE 的数学难度。它解决的是密钥管理和 signing authority resilience。RSS 不是 Shamir sharing。本文更关注 replicated pieces、access structure 和局部短性。Global rejection 不能替代 HRej。局部候选一旦泄漏事后拒绝已经太晚。HRej 不只是性能优化。它首先是隐藏局部 secret-dependent shift 的证明工具。不是越大越好。它受 geometry、proof condition 和 verification bounds 共同约束。不是免费加速。它用通信和计算换成功概率与 latency。p-termination 不要求每次都成功。合法 abort 是协议语义的一部分。Lemma 3.1 不等于不可伪造性证明。它只是局部分布替换工具。Theorem 3.2 不只依赖 MLWE。还需要 ML-DSA UF、ROM 和 Rényi 等。Figure 7 证明的是验证兼容不是内部协议已标准化。Hint 不恢复完整低位。它只辅助恢复 challenge 所需 high bits。A posteriori sharing 不是无损拆分。存在 hint-MLWE caveat。DKG 不等于 a posteriori sharing。一个生成新 key一个拆旧 key。WAN benchmark 不是通用部署保证。本文不是 AI4Lattice 论文。AI4Lattice 只能作为后续方法论启发。对 PQC / 格密码研究的启发以下内容属于研究启发不是论文作者明确提出的新结论。19.1 标准兼容性本身是一种约束驱动创新很多密码学构造可以通过修改公钥、签名或 Verify 获得更简单设计但本文选择保留标准 ML-DSA-style verification。这种约束使构造更难却也更接近真实迁移问题。19.2 参数表是证明、实现和 benchmark 的接口本文参数链说明参数不是论文末尾的附属数字独立重建参数、检查理论 bound 与实测 acceptance 的差距、明确 heuristic assumptions都是有意义的研究工作。19.3 失败语义必须进入 benchmark对带 abort 的方案只报告单次 attempt latency 可能不够。更有意义的指标包括每个成功签名的平均成本local/global abort 比例retry count distributionper-party 与 total communicationnetwork-inclusive latency。19.4 Protocol state 是密码学证明与代码之间的接口commit–reveal、active set、message、party identity、session 和 state single-use 必须正确绑定。即使代数公式正确状态机错误仍可能破坏证明假设。参考资料Sofía Celi, Rafael del Pino, Thomas Espitau, Guilhem Niot, Thomas Prest. Efficient Threshold ML-DSA. Full Version, USENIX Security 2026.NIST. FIPS 204: Module-Lattice-Based Digital Signature Standard.CRYSTALS-Dilithium Team. CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme.CRYSTALS-Dilithium specification and NIST PQC submission documents.Vadim Lyubashevsky. Fiat-Shamir with Aborts: Applications to Lattice and Factoring-Based Signatures.Vadim Lyubashevsky. Lattice Signatures without Trapdoors.格密码基础资料中关于 Sigma-protocol、Fiat-Shamir、MLWE、MSIS、rounding 与 rejection sampling 的章节。论文 bibliography 中的 Finally!、Trilithium、Bienstock et al.、Raccoon / T-Raccoon / Ringtail 等 related work完整元数据仍按本文 TODO_VERIFY 逐项核验。