RSA vs. ML-DSA：256 字节与 2,420 字节签名的对比

RSA 已经为互联网的证书签名了三十年。NIST 于 2024 年 8 月最终确定的 ML-DSA，正是为在量子计算机使 RSA 的数学问题在实践中可解之后接替它而构建的算法。问题在于，ML-DSA 签名比 RSA 大 5 到 18 倍，而这一事实正在重塑银行、云服务提供商和证书颁发机构未来五年的基础设施支出规划。

1. 为什么 RSA 的时间不多了
2. 什么是 ML-DSA，NIST 为什么选择它？
3. RSA 与 ML-DSA：核心规格对比表
4. 签名与密钥大小：逐字节的差距
5. 基准测试结果：签名与验证速度
6. 更大的签名实际代价：带宽、TLS 与存储
7. NIST 安全等级，用通俗语言解释
8. CNSA 2.0 与政府迁移截止日期
9. 实际采用情况：谁已经在交付 ML-DSA
10. 混合签名：同时运行两种算法
11. 生成密钥：你的代码中有什么变化
12. 迁移指南：从 RSA 到 ML-DSA 的八个步骤
13. 五个用例：为任务选择正确的算法
14. SLH-DSA 与混合经典方案仍然适用的场景
15. 优缺点
1. RSA
2. ML-DSA
16. 从业者怎么说
17. 结论：你究竟应该部署哪一个？
18. 常见问题
1. RSA 现在被攻破了吗？
2. 为什么 ML-DSA 的签名比 RSA 大这么多？
3. 我能在当前的证书颁发机构中使用 ML-DSA 吗？
4. ML-DSA-44、ML-DSA-65 和 ML-DSA-87 有什么区别？
5. 切换到 ML-DSA 会花更多钱吗？
6. ML-DSA 和 Dilithium 是同一个东西吗？
7. 小企业现在需要担心这次迁移吗？
8. 如果我的硬件安全模块不支持 ML-DSA，我该怎么办？
9. 相关报道

这篇对比文章将逐一梳理实际数字：直接来自 FIPS 204 规范的签名与密钥大小、来自 liboqs 和 Cloudflare 自身测试的基准范围、联邦承包商已经在跟踪的 CNSA 2.0 截止日期，以及哪些公司在 2025 年和 2026 年已将 ML-DSA 支持投入生产。读完后，你将确切知道在何处部署哪种算法，以及何时部署。

这一切都不再是假设。OpenSSL 一年多前就发布了原生 ML-DSA 支持，各大云密钥管理服务已经允许你选择它，而针对美国国家安全系统的硬性监管截止日期是 2027 年 1 月 1 日。对于 2026 年 10 月的大多数工程团队来说，问题不是 ML-DSA 是否重要，而是哪些系统需要优先使用它，哪些可以安全地等待。

为什么 RSA 的时间不多了

RSA 签名依赖于分解两个大质数乘积的难度。这个问题在经典计算机面前已经支撑了 40 多年。但在足够大、具备容错能力的量子计算机上运行 Shor 算法时，它就无法支撑了——Shor 算法可以在多项式时间内分解 RSA 模数，而经典计算机需要指数时间。

如今没有任何量子计算机能够在密码学相关规模上分解 RSA-2048。已发表的关于所需条件的估算差异很大，从数百到数千个逻辑量子比特不等，而一旦计入纠错开销，这可能意味着数百万个物理量子比特。并不存在一个公认的“RSA 破解日期”，而且随着量子硬件架构的演进，严肃的估算也在不断变化。

更紧迫的问题不是未来的破解，而是当下的破解：先收集，后解密。攻击者今天可以记录加密流量并留存起来，直到出现有能力的量子计算机，然后追溯性地解密一切。签名则带来一种相关但不同的风险。一旦量子攻击变得可行，对手就可以伪造证书、代码签名包和身份验证令牌上的 RSA 签名，而这些签名原本从未打算在几十年后仍被验证。这正是 ML-DSA 旨在填补的空白。

什么是 ML-DSA，NIST 为何选择它？

ML-DSA 代表基于模格的数字签名算法。NIST 于 2024 年 8 月 13 日将其定为 FIPS 204，同时还有 ML-KEM（FIPS 203，用于密钥交换）和 SLH-DSA（FIPS 205，一种基于哈希的备用签名方案）。在标准化之前，ML-DSA 以其最初的研究名称 CRYSTALS-Dilithium 参与竞争并胜出。

ML-DSA 的安全性并非基于分解大数，而是基于某些格问题的困难性，具体来说是在高维结构化格中寻找短向量。这种数学问题被认为能够抵御经典和量子攻击，包括 Shor 算法，因为目前已知没有方法能高效解决格问题。

FIPS 204 定义了三个参数集：ML-DSA-44、ML-DSA-65 和 ML-DSA-87。这些数字指的是内部格维度参数，而非密钥或签名大小，所以不要把它们理解为字节数。每个参数集对应 NIST 五个安全类别之一，而选择正确的那一个是任何从 RSA 迁移的团队必须做出的第一个真正决定。

RSA 与 ML-DSA：核心规格对比表

以下是并排对比，数据取自 FIPS 204 规范和 NIST 公布的安全类别映射。

上述 RSA 密钥大小是近似值，因为字节数在很大程度上取决于编码方式：原始模数和指数、PKCS#1 DER、PKCS#8 DER 以及 PEM（通过 Base64 封装大约增加三分之一的大小）对于“相同”的密钥都会产生不同的数字。相比之下，ML-DSA 的数值在 FIPS 204 表 2 中被精确固定，这也是基于格的方案更容易进行一致性基准测试的部分原因。

签名与密钥大小：逐字节的差距

在任何 RSA 与 ML-DSA 的讨论中，最引人注目的数字是签名大小差距。一个 RSA-2048 签名占 256 字节。换成 ML-DSA-44，同样的签名会膨胀到 2,420 字节，增加了 9.5 倍。再升级到 ML-DSA-87——CNSA 2.0 针对国家安全系统所瞄准的参数集——单个签名达到 4,627 字节，大约是其替代的 RSA-2048 签名的 18 倍。

公钥遵循同样的模式，尽管不那么剧烈。ML-DSA-44 的 1,312 字节公钥已经超过了通常编码的最大 RSA-4096 公钥。私钥的差异最大：ML-DSA-87 的 4,896 字节私钥与 PKCS#8 编码的 RSA-4096 私钥相当，因此私钥开销没有签名开销那么令人痛苦。

这种不对称性很重要，因为签名会在每一次 TLS 握手、每一次代码签名验证和每一次文档检查中通过网络传输。私钥大多存放在磁盘上或 HSM 内部，从不离开。迁移到 ML-DSA 的实际成本几乎完全体现在与签名和公钥相关的网络和存储开销上，而不是私钥存储。

基准测试结果：签名与验证速度

原始速度比大小更能说明一个宽容的故事。来自 Open Quantum Safe 项目 liboqs 库的基准测试，与 Cloudflare 自己的后量子签名测试以及 systemshardening.com 发布的独立测量结果相互参照，即使确切的吞吐量数字会随 CPU 型号、编译器标志以及是否启用 AVX2 或 AVX-512 向量化而波动，也呈现出一致的模式。

值得记住的模式：RSA 的验证步骤是其最大优势，通常比其自身的签名步骤快一个数量级，这正是 RSA 长期主导 TLS 服务器证书的原因（客户端验证的频率远高于服务器签名）。ML-DSA 的签名和验证成本彼此接近得多，这改变了对持续签名的服务的性能考量，例如代码签名流水线或高频 API 认证，在这些场景中，ML-DSA 更均衡的特性实际上可能领先，尽管输出更大。

把那张表中的每个数字都视为一个范围，而不是一个常量。liboqs 的结果应始终附带库版本、编译器和 CPU 型号，因为在一台机器上显示每秒 20,000 次操作、在另一台机器上显示 2,000 次的基准测试并不矛盾，而是两种不同的硬件和实现配置。

更大的签名实际代价：带宽、TLS 和存储

签名大小差异在乘以每天数百万次连接的那一刻就不再是学术问题。一个携带 ML-DSA-87 签名的 TLS 1.3 CertificateVerify 消息，仅签名负载就大约 4.6 KB，这还没有算上证书数据和握手帧。与等效的 RSA 或 ECDSA 链相比，端到端使用 ML-DSA-65 签名的完整证书链可能增加 10 KB 或更多。

目前没有任何主要云密钥管理服务按签名算法额外收费。AWS KMS 和 Google Cloud KMS 对 ML-DSA 签名的计费方式与任何其他非对称签名操作相同，均通过标准的按 API 调用定价。这次迁移的真正成本不是云账单上的一个项目，而是花在库升级上的工程时间、因超大 ASN.1 字段而卡住的基础设施，以及在规模上悄然侵蚀带宽预算的证书链膨胀。

用通俗语言解释 NIST 安全级别

NIST 为后量子算法定义了五个安全类别，每个类别都与破解一个参考经典算法所需的计算量挂钩。ML-DSA-44 属于第 2 类，大致相当于找到 SHA-256 碰撞所需的计算量。ML-DSA-65 属于第 3 类，相当于暴力破解 AES-192。ML-DSA-87 属于第 5 类，相当于破解 AES-256。

在实践中，大多数组织将 ML-DSA-65 作为默认选择，就像多年来 RSA-2048 而非 RSA-4096 成为默认选择一样：它在安全裕度与大小和性能成本之间取得平衡。ML-DSA-87 则保留给监管要求的情况，主要是美国国家安全系统的 CNSA 2.0 合规，或者组织希望为需要保持数十年可信的数据或签名提供最大的长期裕度。

CNSA 2.0 与政府迁移截止日期

NSA 的商业国家安全算法套件 2.0 是推动 2026 年 ML-DSA 采用的最明确截止日期，尽管它严格来说只适用于国家安全系统，而非该国的每个商业实体。

• 2027 年 1 月 1 日：所有新的国家安全系统采购必须使用符合 CNSA 2.0 的算法，对于签名而言即 ML-DSA-87。
• 到 2030 年：各组织应已启动积极的迁移规划与采购，在新部署中逐步淘汰经典算法。
• 到 2033 年：CNSA 2.0 要求在所有适用系统中独家使用新算法套件，具体以 NSA 的实施指南为准。

CNSA 2.0 还要求通过 ML-KEM 实现后量子密钥建立，而不仅仅是后量子签名，因此同时涉及加密和签名基础设施的承包商正面临双线迁移。这些截止日期在法律上并不约束普通商业公司或民用机构，但国防承包商、其供应商以及任何向该采购链销售产品的一方，无论具体合同目前是否要求，都已在 2026 和 2027 年的产品路线图中构建对 ML-DSA-87 的支持。

与此同时，CA/Browser Forum 一直在按其自身独立的时间表缩短公共 TLS 证书的有效期：最长有效期于 2026 年 3 月 15 日降至 200 天，计划于 2027 年 3 月 15 日降至 100 天，并于 2029 年 3 月 15 日降至 47 天。该时间表并非 ML-DSA 强制要求，但更短有效期的证书推动每个 CA 走向更重的自动化，而这恰好使未来在公共 PKI 支持到位后向后量子签名切换在操作上更容易。

现实世界采用：谁已在交付 ML-DSA

ML-DSA 从纸面标准走向实际产品的速度比大多数后量子算法都快，主要因为 OpenSSL 3.5.0——2025 年 4 月 8 日发布的长期支持版本——将原生 ML-KEM、ML-DSA 和 SLH-DSA 支持带入默认提供程序，无需外部补丁。这一个版本对加速 ML-DSA 在现实世界中的采用所起的作用，超过任何单个厂商的公告，因为它一举消除了最大的实际障碍：需要非标准库或手工编写的补丁。

• Cloudflare 已在其边缘到源站路径上部署 ML-DSA 支持，覆盖 Authenticated Origin Pulls 及其 Custom Origin Trust Store，并在 Free、Pro 和 Business 各档中推出。另外，截至 2025 年 9 月中旬，Cloudflare 的混合 ML-KEM 密钥交换保护了约 43% 的人类生成连接，该比例在 2026 年持续攀升。
• AWS KMS 于 2025 年新增了对全部三种参数集（ML-DSA-44、-65、-87）的 ML-DSA 签名支持，截至 2026 年 8 月确认仍有效，按其标准非对称签名定价计费。
• Google Cloud KMS 现在将 ML-DSA 作为可选的签名选项提供，由客户明确选择启用，而非默认开启。
• Microsoft 已将 ML-KEM 和 ML-DSA 构建到其 SymCrypt 加密库中，相关支持正在 Azure 和 Windows 生态系统的部分组件中逐步推出。
• Oracle 发布了 Java 27 及 Oracle Jipher 20，这是一个通过 FIPS 140-3 验证、基于 OpenSSL 的模块，同时支持 ML-KEM 和 ML-DSA，于 2026 年 9 月宣布。
• Ubuntu 26.10 基于 OpenSSL 4.0 发布，开箱即提供 ML-KEM、ML-DSA 和 SLH-DSA，并将混合后量子密钥交换设为默认首选。
• Red Hat 的 RHEL 10 以技术预览形式包含了初步的纯 ML-DSA 支持，其构建基于 IETF 的 draft-ietf-lamps-dilithium-certificates 规范，该规范仍在演进中。

值得明确区分的是：Apple 的 PQ3 消息协议和 Signal 的 PQXDH 都依赖 ML-KEM 式的密钥建立来实现前向保密，而非 ML-DSA 签名。这是一个有意义的区别。ML-KEM 保护会话密钥的机密性，而 ML-DSA 保护签名、证书和身份验证。一个消息应用在加密上实现了后量子，并不意味着它在签名上也实现了后量子，将两者混为一谈会夸大签名迁移在整个行业中的实际进展。

面向普通网站的、受浏览器信任的公共 ML-DSA 证书仍是瓶颈。IETF 于 2025 年 10 月发布了 RFC 9881，定义了如何在 X.509 证书中携带 ML-DSA 密钥和签名，但主要商业证书颁发机构在获得浏览器和操作系统完全信任的情况下进行广泛的公共签发，预计要到 2026 年底或 2027 年，而非现在就能实现。

混合签名：同时运行两种算法

由于纯 ML-DSA 证书的公共 PKI 信任尚未完全到位，2026 年的大多数生产部署依赖混合签名：将经典算法与 ML-DSA 配对，使得只有当两个组件都验证通过时验证才成功，或者构造单个证书来同时携带两种签名。常见的配对包括 ECDSA P-256 与 ML-DSA-44、ECDSA P-384 与 ML-DSA-65，以及 RSA-3072 或 RSA-4096 与 ML-DSA-65 或 ML-DSA-87。

混合模式带来了算法多样性和对尚不支持 ML-DSA 的系统的向后兼容性，代价是更大的证书、更多的验证工作以及更复杂的证书管理逻辑（你要求两个签名都验证通过，还是接受其中任意一个？）。如今在 TLS 中，混合密钥交换比混合签名认证要成熟得多，这就是为什么你在生产环境中能找到的大多数 2026 年部署都使用经典签名搭配混合 ML-KEM 密钥交换，而将完整的 ML-DSA 签名保留用于内部 PKI、代码签名以及运营方控制信任关系两端的系统。

围绕混合验证的策略决策，其重要性实际上超过了密码学本身。严格的“两者都必须验证通过”策略最大化了安全裕度，但意味着任一算法中的漏洞或密钥管理故障都会破坏整条链。较宽松的“任一即可”策略在一个算法失败时仍能保持系统运行，但只提供攻击者选择攻击的那个算法的安全级别。迄今为止记录的大多数生产部署倾向于要求两者都通过，接受运营风险，以换取不会在某一个算法遇到障碍时悄然降低安全性。

生成密钥：你的代码中有什么变化

对开发者而言，RSA 与 ML-DSA 密钥生成之间的实际差异比尺寸数字所暗示的要小。在 OpenSSL 3.5 或更高版本上，两种算法都通过相同的通用 EVP 密钥生成 API，只是传入的算法名称不同。在常见情况下，没有单独的特殊工具链需要学习。

# Generate an RSA-3072 key pair (classical, pre-existing workflow)
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa3072.key

# Generate an ML-DSA-65 key pair (requires OpenSSL 3.5.0 or later)
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key

# Sign a file with each key
openssl pkeyutl -sign -inkey rsa3072.key -in message.txt -out rsa.sig
openssl pkeyutl -sign -inkey mldsa65.key -in message.txt -out mldsa.sig

# Compare signature sizes directly
ls -l rsa.sig mldsa.sig

自己运行一下最后的对比，尺寸差距就不再是抽象的表格，而是一个 384 字节的文件与一个 3,309 字节的文件并排摆在那里。这就是整个迁移故事的缩影：相同的工作流，相同的命令结构，输出大小却天差地别。那些运行自定义 C 或 Rust 加密代码、而非调用 OpenSSL CLI 的团队，会调用等效的 EVP_PKEY_CTX_new_from_name 函数，将 "ML-DSA-65" 作为算法标识符，随后使用库中所有其他基于 EVP 的算法早已使用的标准 EVP_PKEY_keygen_init 和 EVP_PKEY_keygen 调用。

迁移指南：从 RSA 到 ML-DSA 的八个步骤

将真实的生产系统从 RSA 签名迁移出去，绝非一个周末就能完成的项目。以下这套流程无论你是迁移单个服务还是整个 PKI 都适用。

1. 清点每一个签名接触点。TLS 证书、代码签名密钥、JWT 签名、SSH 主机密钥、VPN 认证、文档签名、固件更新验证。大多数团队都会把这份清单低估一半。
2. 升级你的加密栈。OpenSSL 3.5.0 或更高版本原生支持 ML-DSA，无需外部 provider。较旧的栈可以通过 liboqs 和 oqs-provider 插件进行桥接，不过 oqs-provider 现在检测到底层有原生 OpenSSL 3.5+ 支持时，会自动禁用其自身的 ML-DSA 实现。
3. 审慎选择参数集。ML-DSA-44 适用于较低保障或尺寸受限的场景，ML-DSA-65 是大多数服务的合理默认值，ML-DSA-87 仅在 CNSA 2.0 或明确的高保障要求需要时才使用。
4. 从混合签名开始，而非纯 ML-DSA。将 ML-DSA 与你现有的 RSA 或 ECDSA 签名配对使用，直到公共信任存储、CA 和客户端软件跟上为止。
5. 在你实际的硬件上进行基准测试。厂商公布的吞吐量数字基于特定的 CPU、编译器和向量指令集。在承诺采用某个参数集之前，先在你自己的生产等效机器上运行 liboqs 基准测试。
6. 审计对尺寸敏感的基础设施。负载均衡器、旧式 ASN.1 解析器、证书透明度日志提交和 OCSP 响应器，可能会对为 256 字节 RSA 签名（而非 4.6 KB 的 ML-DSA 签名）构建的超大证书字段感到吃力，或将其静默截断。
7. 与你的证书颁发机构协调。直接询问混合或 ML-DSA 证书的时间表，而不是想当然地认为可用。DigiCert 和 AWS Private CA 都已释放出生产路径的信号，但要确认今天针对你的具体用例实际可签发的是什么。
8. 设置一个周期性的加密敏捷性检查点。对照 CNSA 2.0 的 2027 年 1 月、2030 年和 2033 年里程碑，或你组织的内部 PQC 截止日期，重新评估你的迁移状态，而不是把它当作一个有终点线的一次性项目。

五个用例：为任务选择正确的算法

当今面向公众的 TLS Web 服务器。继续使用 RSA 或 ECDSA 服务器证书，并搭配混合 ML-KEM 密钥交换来保障机密性。纯 ML-DSA 证书尚未被浏览器广泛信任，过早追求它们只会增加握手开销，却换不来兼容性上的回报。

国防承包商和国家安全系统。现在就迁移到 ML-DSA-87，而不是等到 2027 年。CNSA 2.0 针对新采购的截止日期是 2027 年 1 月 1 日，而采购、测试和认证周期会消耗掉你不想白白失去的几个月时间。

代码签名与软件供应链。 如今就用经典签名和 ML-DSA 双重签名来签署固件、操作系统更新和软件包。已签名的制品可能会流通多年，而这正是量子攻击变得可行后，对手可能瞄准的那种长期有效的签名。

企业内部 PKI 与设备身份。 这是最早采用 ML-DSA 阻力最小的场景。信任关系的两端都由你掌控，主流云平台已通过 AWS KMS、Google Cloud KMS 和 Microsoft 的 SymCrypt 提供支持，而且无需等待公共浏览器信任存储。

带宽受限的 IoT、嵌入式和卫星链路。 在这里采用 ML-DSA 前要三思。4.6 KB 的签名对窄带或按流量计费的链路是实实在在的负担。在威胁模型允许的情况下继续使用 RSA 或 ECDSA，或者评估 SLH-DSA 以及其他专为受限环境设计的紧凑替代方案。

长期文档与法律签名。 合同、公证记录以及需要数十年保持可验证的归档签名，现在就应该迁移到 ML-DSA 或混合签名。后量子签名的全部意义就在于保护那些需要比经典密码学时代更长久存在的东西，而一份 30 年租约上的签名就是教科书式的案例。

SLH-DSA 与混合经典方案仍然适用的场景

ML-DSA 并不是 NIST 标准化的唯一后量子签名，把它当作唯一选项会低估团队实际面临的选择。SLH-DSA（FIPS 205，原 SPHINCS+）完全依赖哈希函数而非格数学，因此如果基于格的密码分析进展超出预期，它可以作为有用的后备方案。其取舍与 ML-DSA 相反：SLH-DSA 签名大得多，通常达数十 KB，且签名速度明显更慢，因此它被保留用于高保障的后备角色，而非日常 TLS 或 API 认证。

还有 FN-DSA（基于 Falcon 设计的 FIPS 204 姊妹标准），它生成的签名比 ML-DSA 更小，但签名过程更窄、更难实现，导致采用速度较慢。对于大多数不属于专业高保障或空间受限部署的团队来说，实际决策树仍然始于并终于 ML-DSA：它拥有最广泛的库支持，来自 Cloudflare、AWS、Google 和 Microsoft 的最明确采用信号，以及截至 2026 年 10 月最成熟的工具链。

这一切都不会改变 RSA 与 ML-DSA 对比的核心结论，但对于评估仅靠 ML-DSA 是否覆盖其整个签名策略的团队来说，这很重要。纵深防御姿态——国家安全系统和长期归档签名者越来越青睐的那种——将 ML-DSA 作为主要后量子签名，与 SLH-DSA 作为结构上独立的后备方案配对，这样某一种数学方法的弱点就不会同时击垮两种签名。

优缺点

RSA

• 签名小至 256 字节，带宽和存储开销极低
• 过去 20 年构建的每个浏览器、操作系统、库和设备都普遍支持
• 验证速度极快，通常比签名快一个数量级
• 数十年的密码分析和真实世界实战检验
• 不抗量子，一旦出现有能力的硬件，原则上易受 Shor 算法攻击
• 随着密钥大小向 RSA-4096 增长，签名成本急剧上升
• 对任何需要在2030年代之后仍保持可信的事物承担长期责任

ML-DSA

• 由NIST标准化（FIPS 204），旨在抵御量子攻击
• 签名速度与RSA相当，有时甚至更快
• 已在OpenSSL 3.5+、AWS KMS、Google Cloud KMS和Microsoft SymCrypt中原生支持
• 签名与验证的性能比RSA更均衡
• 签名比RSA-2048大9到18倍，给带宽和旧式解析器带来压力
• 公开的、受浏览器信任的证书尚未广泛可用
• 较新的算法，累积的真实世界密码分析审查少于RSA

从业者怎么说

Cloudflare的密码学工程师David Adrian直白地描述了该领域的现状：“ML-DSA是当今已标准化的最可行的通用后量子签名方案”（来源）。考虑到Cloudflare运营着互联网上一些最繁忙的TLS基础设施，并能直接洞察在生产负载下真正经得起考验的东西，这是一个值得注意的声明。

Cloudflare的安全团队对近期缺乏替代方案也同样直言不讳：“幸运的是，解决方案已经可用：迁移到ML-KEM加密和ML-DSA签名，它们旨在抵御量子攻击”（来源）。这一表述很重要：这并非被呈现为完美的修复方案，而是在NIST标准化已落地的情况下可用的修复方案。

Oracle自己的数据库文档对其预期的发展轨迹毫不讳言：“ML-DSA旨在取代RSA和ECDSA”（来源），这句话出现在企业供应商文档中，正是因为客户在询问供应商其后量子路线图是什么样子。

而NIST自己的FIPS 204标准以其一贯低调的措辞描述了其范围：“本标准规定了ML-DSA，一组可用于生成和验证数字签名的算法”（来源）。这种低调掩盖了这短短一句话背后所蕴含的大量工程工作。

结论：你究竟应该部署哪一个？

两种算法都没有取得压倒性胜利，因为它们实际上已不再为同一项任务而竞争。对于当今需要普遍兼容性的任何事物，RSA仍是务实的默认选择：公开TLS证书、旧式设备认证，以及256字节签名比抗量子性更重要的系统。它在2026年或2027年不会消失，鉴于互联网信任基础设施的很大一部分仍依赖于它能在任何地方即时运行，将其视为已经过时还为时过早。

在长期签名有效性比带宽效率更重要、且监管时钟已经在走的地方，ML-DSA是正确的选择。这意味着受CNSA 2.0约束的政府和国防系统现在就应该迁移到ML-DSA-87，而不是等到2027年1月的截止日期来迫使问题解决。这意味着代码签名流水线和软件供应链今天就应该采用RSA加ML-DSA的混合双重签名，因为2026年签名的固件镜像到2036年可能仍在运行。这也意味着内部企业PKI——你控制信任链两端——是在公开信任基础设施迫使你采取行动之前，开始积累新算法运营经验的最简单、风险最低的起点。

唯一确定的是：256 字节 RSA 签名作为互联网默认选项长达三十年的历程即将结束，只是不会一夜之间完成，也不会同时在所有地方发生。那些将其视为二元开关、在 RSA 失效当天才切换的团队，将会手忙脚乱。而那些将其视为分阶段迁移的团队——现在采用混合方案，在合理之处选择性地使用纯 ML-DSA，待公共 PKI 跟上后再全面切换——几乎不会察觉到过渡的发生。

常见问题

RSA 现在被破解了吗？

没有。目前没有任何量子计算机能够以威胁现实部署的规模分解 RSA-2048。风险是前瞻性的：针对加密数据的“先收集、后解密”，以及针对长期有效签名的未来伪造风险，而非当前的实际破解。

为什么 ML-DSA 的签名比 RSA 大这么多？

基于格的签名方案从根本上需要更多数据来编码使伪造困难的数学证明。RSA 将其证明压缩为单个模幂运算结果，而 ML-DSA 编码多个多项式向量，无论实现质量如何，这本质上都更大。

我可以在当前的证书颁发机构中使用 ML-DSA 吗？

这取决于 CA 和您的使用场景。私有和企业 CA 如今可以使用 OpenSSL 3.5+ 或 AWS Private CA 签发 ML-DSA 证书。广泛的公共、浏览器信任的 ML-DSA 证书签发预计仍在 2026 年底或 2027 年，等待 CA/Browser Forum 基线要求更新。

ML-DSA-44、ML-DSA-65 和 ML-DSA-87 之间有什么区别？

它们是三个参数集，分别对应 NIST 安全类别 2、3 和 5，其中 ML-DSA-65 是通常推荐的默认选项，ML-DSA-87 则保留用于高保证或 CNSA 2.0 强制要求的部署。

切换到 ML-DSA 会花费更多钱吗？

AWS 和 Google Cloud 等云 KMS 提供商对 ML-DSA 签名的计费与任何其他非对称签名操作相同，因此没有直接的每次签名价格上涨。真正的成本体现在库升级的工程时间、超大字段的基础设施更新，以及大规模下更大证书和握手带来的额外带宽。

ML-DSA 和 Dilithium 是同一个东西吗？

是的。CRYSTALS-Dilithium 是该算法在 NIST 评估过程中的名称。ML-DSA 是 FIPS 204 下的官方标准化名称，于 2024 年 8 月 13 日最终确定。

小企业现在应该担心这次迁移吗？

不紧急，除非您处于受监管行业、处理长期有效的签名制品，或向政府供应链销售。大多数小企业可以等待公共 CA 支持和主流库默认值成熟后再接触生产签名基础设施。

如果我的硬件安全模块不支持 ML-DSA 该怎么办？

请向您的 HSM 供应商咨询固件或软件更新路线图，因为主要供应商在 FIPS 204 最终确定后一直在添加支持。与此同时，如果您需要比本地 HSM 供应商更早获得生产能力，AWS KMS 和 Google Cloud KMS 都提供托管的 ML-DSA 签名。对于密钥不能离开经过验证的硬件边界的受监管环境，请特别向您的供应商询问 ML-DSA 的 FIPS 140-3 验证状态，因为算法支持和正式验证通常按不同的时间表发布。

相关报道

• LMS vs XMSS：1,432 字节 vs 2,500 字节签名 [2026]
• FN-DSA vs ML-DSA：666 字节签名，2 年标准差距 [2026]
• Merkle 与 Verkle 树：从 1KB 到 150 字节证明 [2026]
• 椭圆曲线密码学与 RSA：快 14 倍 [2026]
• MD5 与 SHA-256：SHA-256 现已快 4 倍 [2026]