2. ML-DSA算法族谱与选型

ML-DSA并不是凭空出现的新算法，它的前身是NIST后量子密码标准化竞赛中的CRYSTALS-Dilithium。理解这条演进链，是工程选型的第一步：Dilithium在竞赛中提交了多个参数集，最终FIPS 204只保留了三个标准化参数集，并统一命名为ML-DSA-44、ML-DSA-65、ML-DSA-87。名字中的数字并非版本号，而是对应模块格维度参数(k, l)的取值：44表示k=4、l=4，65表示k=6、l=5，87表示k=8、l=7。维度越大，签名与公钥越大，安全强度越高，但计算与带宽开销也越大。

从Dilithium到FIPS 204，核心算法结构没有根本改变，仍是基于模块格上Fiat-Shamir with Aborts范式的签名方案：密钥生成产生矩阵A与短向量s1、s2；签名时对消息哈希后采样掩码向量y，计算w=Ay，再通过挑战c生成z=y+c·s1，并反复拒绝采样直到z和r0的范数满足阈值；验证时检查Az−c·t1的范数与哈希一致性。FIPS 204的主要变化在于：参数集固定为三档、采样与编码细节被规范化、增加了确定性签名与随机签名的明确接口、对上下文串(context)和消息预处理做了标准化定义，并给出了明确的密钥与签名编码长度。这些变化让不同实现之间可以互操作，也让工程选型有了稳定的参照。

三个参数集的关键差异可以用一张参数关系图来直观呈现。下图把安全等级、公钥/私钥/签名尺寸、以及相对性能取向放在同一视图中，便于在选型时快速比较。

从图中可以读出三条工程结论。第一，安全等级与尺寸并非线性增长：从44到65，公钥增长约49%，签名增长约37%；从65到87，公钥再增长约33%，签名再增长约40%。第二，签名尺寸普遍大于公钥，这意味着在证书链、握手等场景中，签名传输往往是带宽瓶颈，而不是公钥。第三，挑战熵从192 bit到257 bit，直接对应安全等级2/3/5，选型时不能只看“够不够快”，还要看合规要求是否指定了最低等级。

工程选型时，建议按以下决策逻辑推进。首先明确合规基线：如果系统需要满足NIST安全等级3或等效要求，65通常是默认起点；如果面向长期归档或根信任锚，87更稳妥；如果资源受限且威胁模型允许等级2，44可以显著降低带宽与存储。其次评估协议约束：TLS 1.3的CertificateVerify和证书链会放大签名尺寸，44与65的差异在移动网络下可能直接影响握手时延；代码签名与固件更新则更关注验签速度与公钥缓存，65往往是最佳平衡点。再次考虑实现成熟度：三个参数集共享同一套核心代码，切换通常只需替换参数结构体与长度常量，但采样拒绝率、NTT长度和向量维度会变化，必须重新做侧信道与性能回归测试。

下面给出一份可直接参考的工程选型决策表，字段只保留与ML-DSA选型真正相关的维度。

最后需要强调，ML-DSA-44/65/87不是“好/更好/最好”的简单排序，而是面向不同约束的三档工程折中。实际部署中，混合模式（如X25519+ML-DSA-65）常被用来兼顾经典安全与后量子安全；而在纯后量子场景下，65通常是最容易落地的默认档。无论选择哪一档，都应在目标硬件上实测密钥生成、签名、验签的吞吐与尾延迟，并确认随机数源、上下文串编码和消息预处理与FIPS 204一致，否则互操作性会在联调阶段暴露问题。