密码学 / 高级 / 14 分钟

后量子密码学(ML-DSA、SLH-DSA)

面向可验证凭证的抗量子签名——在量子计算机攻破 RSA 和 ECC 之前实现面向未来的密码学

问题所在:量子计算机将攻破今天的密码学

当前的密码学方案(RSA、ECDSA、Ed25519)都依赖困难的数学问题

  • RSA:对大数进行因数分解(2048 位 → 约 617 位十进制数字)
  • ECDSA:椭圆曲线上的离散对数问题
  • Ed25519:ECDSA 的一种变体(Curve25519)

这些方案在今天是安全的,因为经典计算机需要数十亿年才能破解它们。

但量子计算机改变了这一切:

  • Shor 算法(1994 年):一种能在多项式时间内对大数进行因数分解、并求解离散对数问题的量子算法
  • 实用型量子计算机(10,000+ 逻辑量子比特):能在数小时到数天内攻破 RSA-2048、ECDSA-256、Ed25519

时间线:

  • 2019 年:Google 的 Sycamore 处理器(53 量子比特)展示”量子霸权”(在特定任务上比经典计算机更快)
  • 2023 年:IBM Condor(1,121 量子比特)——但这些是物理量子比特,而非容错的逻辑量子比特
  • 2030-2035 年(预估):具有密码学相关性的量子计算机(CRQC)——10,000+ 逻辑量子比特,可攻破 RSA/ECC

这一威胁是真实存在的:

  • “现在存储,未来解密”攻击:攻击者今天记录加密的凭证,等量子计算机问世后再解密
  • 长期有效的凭证:2026 年签发,2036 年到期——量子计算机可能在其生命周期中途就攻破它
  • 身份基础设施:DID、可验证凭证、信任注册表——全部依赖 RSA/ECDSA 签名

**后量子密码学(PQC)**解决了这个问题:由 NIST(美国国家标准与技术研究院)标准化的、能抵御量子攻击的密码学算法。


什么是后量子密码学?

后量子密码学(PQC) 指的是那些即便攻击者拥有量子计算机也依然安全的密码学算法。

核心洞察: PQC 算法依赖的数学问题对经典计算机和量子计算机都同样困难

NIST 后量子密码学标准化进程(2016-2024)

时间线:

  • 2016 年:NIST 宣布启动 PQC 标准化流程
  • 2022 年:NIST 选出决赛算法(4 种)
  • 2024 年:NIST 发布 FIPS 203、204、205(正式标准)

已选定的算法:

  1. ML-KEM(FIPS 203)——密钥封装机制(加密)

    • 基于:CRYSTALS-Kyber
    • 应用场景:加密数据(例如 TLS 握手)
  2. ML-DSA(FIPS 204)——数字签名算法

    • 基于:CRYSTALS-Dilithium
    • 应用场景:为可验证凭证、DID、证书签名
  3. SLH-DSA(FIPS 205)——无状态哈希签名

    • 基于:SPHINCS+
    • 应用场景:为可验证凭证、DID 签名(作为 ML-DSA 的备用方案)

对于可验证凭证,我们关心的是签名算法(ML-DSA、SLH-DSA),而非加密算法(ML-KEM)。


ML-DSA(基于模格的数字签名算法)

什么是 ML-DSA?

ML-DSA(原名 CRYSTALS-Dilithium)是一种**基于格(Lattice)**的签名方案,已标准化为 NIST FIPS 204

安全性基础:

  • 格问题:“最短向量问题”(SVP)与”带误差学习问题”(LWE)
  • 对量子计算机而言难以破解:目前没有已知的高效量子算法(不同于针对 RSA/ECC 的 Shor 算法)
  • 对经典计算机而言也难以破解:时间复杂度呈指数级增长

特性:

  • 抗量子:可抵御 Shor 算法
  • 签名速度快:约 1 毫秒(与 ECDSA 相当)
  • 验证速度快:约 0.5 毫秒
  • 确定性:相同的消息 + 密钥 → 相同的签名(可复现)
  • 签名体积较大:约 2.4 KB(相比 Ed25519 的 64 字节)
  • 公钥体积较大:约 1.3 KB(相比 Ed25519 的 32 字节)

ML-DSA 参数集

NIST 定义了 3 个安全级别:

参数集安全级别签名大小公钥大小相当于
ML-DSA-44级别 2约 2,420 字节约 1,312 字节AES-128 / RSA-2048
ML-DSA-65级别 3约 3,293 字节约 1,952 字节AES-192 / RSA-3072
ML-DSA-87级别 5约 4,595 字节约 2,592 字节AES-256 / RSA-4096

推荐: ML-DSA-65(级别 3)在大多数应用场景下能兼顾安全性与体积。

ML-DSA 示例:为可验证凭证签名

步骤 1:生成密钥

# 生成 ML-DSA-65 密钥对
(public_key, private_key) = ml_dsa_65_keygen()

# 公钥: 1,952 字节 (相比 Ed25519: 32 字节)
# 私钥: 4,032 字节 (相比 Ed25519: 32 字节)

步骤 2:为凭证签名

credential = {
  "type": "VerifiableCredential",
  "issuer": "did:webvh:company-x",
  "credentialSubject": { "name": "Alice", "role": "Engineer" },
  "issuanceDate": "2026-07-22T00:00:00Z"
}

# 序列化凭证 (JSON 规范化)
message = canonicalize_json(credential)

# 使用 ML-DSA-65 签名
signature = ml_dsa_65_sign(private_key, message)

# 签名: 3,293 字节 (相比 Ed25519: 64 字节)

步骤 3:验证签名

# 验证者收到: 凭证 + 签名 + 签发者的公钥
is_valid = ml_dsa_65_verify(public_key, message, signature)

# 结果: True (签名有效) 或 False (无效/已被篡改)

抗量子安全性: 即便攻击者拥有量子计算机,也无法伪造签名(格问题依然困难)。


SLH-DSA(无状态哈希签名算法)

什么是 SLH-DSA?

SLH-DSA(原名 SPHINCS+)是一种基于哈希的签名方案,已标准化为 NIST FIPS 205

安全性基础:

  • 哈希函数:使用 SHA-256 或 SHAKE256(标准的密码学哈希算法)
  • 无结构化问题:不依赖格、纠错码或代数结构
  • 保守型安全:只要哈希函数是安全的,SLH-DSA 就是安全的

特性:

  • 抗量子:哈希函数不存在量子攻击(Grover 算法只能提供二次方加速 → 使用更大的哈希值依然安全)
  • 无需保留密钥状态:无状态(不同于 XMSS 等原始哈希签名方案,那些方案需要跟踪状态)
  • 保守:假设条件最小(只需哈希安全性)
  • 签名速度较慢:约 50-200 毫秒(相比 ML-DSA 约 1 毫秒)
  • 签名体积非常大:约 7-50 KB(相比 ML-DSA 约 2.4 KB)

SLH-DSA 参数集

NIST 定义了多组参数(体积与速度的权衡):

参数集安全级别签名大小公钥大小签名耗时
SLH-DSA-128s级别 1约 7,856 字节32 字节约 50 毫秒
SLH-DSA-128f级别 1约 17,088 字节32 字节约 10 毫秒
SLH-DSA-192s级别 3约 16,224 字节48 字节约 100 毫秒
SLH-DSA-192f级别 3约 35,664 字节48 字节约 20 毫秒
SLH-DSA-256s级别 5约 29,792 字节64 字节约 200 毫秒
SLH-DSA-256f级别 5约 49,856 字节64 字节约 40 毫秒

“s” = 小签名(签名较慢),“f” = 签名快(签名体积大)

推荐: 将 SLH-DSA 用作 ML-DSA 的备用方案(若格密码学的假设失效,可作为保守的兜底选择)。


ML-DSA 与 SLH-DSA:该用哪个?

ML-DSASLH-DSA
安全性基础格(LWE)哈希函数
抗量子安全✓ 是✓ 是
签名速度✓ 快(约 1 毫秒)✗ 慢(50-200 毫秒)
验证速度✓ 快(约 0.5 毫秒)✓ 快(约 1 毫秒)
签名大小⚠ 较大(约 2.4 KB)✗ 非常大(7-50 KB)
公钥大小⚠ 较大(约 1.3 KB)✓ 小(32-64 字节)
成熟度✓ NIST 标准(2024 年)✓ NIST 标准(2024 年)
保守性⚠ 依赖格假设✓ 假设条件最少

主选: 使用 ML-DSA-65(速度快、体积合理、抗量子)。

备用: 使用 SLH-DSA-128s(保守方案,以防格密码学突然出现问题)。

混合方案: 同时使用 ML-DSA + SLH-DSA 进行签名(双重保险——一个失效,另一个依然安全)。


可验证凭证的 PQC:具体实现

现状(2026 年)

目前大多数可验证凭证使用:

  • Ed25519(Curve25519 签名)——快、体积小,但易受量子攻击
  • ECDSA(P-256、secp256k1)——支持广泛,但易受量子攻击
  • RSA(2048-4096 位)——传统方案,但易受量子攻击

均不具备抗量子能力。

Affinidi 的 PQC 路线图

第一阶段(2026 年):混合签名

  • 凭证同时使用 Ed25519 + ML-DSA-65 签名
  • 验证者同时检查两个签名:
    • Ed25519:快、体积小,与当前系统兼容
    • ML-DSA-65:抗量子,面向未来
  • 只要任一签名有效 → 凭证被接受(保持向后兼容)

第二阶段(2027-2028 年):以 ML-DSA 为主

  • 新签发的凭证仅使用 ML-DSA-65
  • 旧版验证者依然接受 Ed25519(渐进式迁移)
  • 信任注册表跟踪:“签发者 X 使用 ML-DSA” → 验证者知道要预期更大的签名

第三阶段(2029 年以后):仅使用后量子方案

  • 所有凭证均使用 ML-DSA 或 SLH-DSA 签名
  • Ed25519/ECDSA 被弃用(届时量子计算机构成真实威胁)
  • 信任注册表强制执行:“仅接受抗量子签名”

带 PQC 密钥的 DID 文档

当前的 DID 文档(Ed25519):

{
  "id": "did:webvh:company-x",
  "verificationMethod": [{
    "id": "did:webvh:company-x#key-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:webvh:company-x",
    "publicKeyMultibase": "z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH"
  }]
}

后量子 DID 文档(ML-DSA):

{
  "id": "did:webvh:company-x",
  "verificationMethod": [
    {
      "id": "did:webvh:company-x#key-1",
      "type": "Dilithium3VerificationKey2024",
      "controller": "did:webvh:company-x",
      "publicKeyMultibase": "z3F... (1,952 字节编码)"
    },
    {
      "id": "did:webvh:company-x#key-2",
      "type": "Ed25519VerificationKey2020",
      "controller": "did:webvh:company-x",
      "publicKeyMultibase": "z6MkpTHR8... (32 字节)"
    }
  ],
  "authentication": ["#key-1", "#key-2"]
}

混合方案: DID 同时拥有 ML-DSA 和 Ed25519 两种密钥——验证者两者都会检查,只要有一个有效即可通过。


迁移挑战

1. 签名体积暴增

问题: ML-DSA 签名比 Ed25519 大 40 倍(2.4 KB 对比 64 字节)。

影响:

  • 二维码:Ed25519 凭证可放入二维码(≤2,953 字节)。ML-DSA 凭证放不下(体积太大)。
  • NFC 标签:存储空间有限(≤4 KB)——ML-DSA 凭证勉强能放下,没有空间容纳多个凭证。
  • 移动带宽:更大的签名意味着更高的数据传输成本(在低带宽地区尤为明显)。

缓解措施:

  • 签名压缩:研究压缩格签名的方法(可减小 20-30% 的体积)
  • 分离式签名:签名单独存储,通过哈希引用(二维码只包含哈希值,验证者再获取签名)
  • 渐进式增强:移动应用通过 WiFi 预取 ML-DSA 签名,本地缓存

2. 验证开销

问题: ML-DSA 验证耗时约 0.5 毫秒(相比 Ed25519 约 0.1 毫秒)——慢 5 倍。

影响:

  • 高吞吐验证场景(例如边检每小时扫描 1,000 本护照):慢 5 倍 = 排队更长
  • 移动设备:格运算的计算密集型操作会消耗更多电量

缓解措施:

  • 硬件加速:ARM CPU 增加格密码学指令集(类似 AES 的 AES-NI)
  • 批量验证:并行验证多个 ML-DSA 签名(分摊开销)
  • 混合模式:对低价值场景(年龄验证)使用 Ed25519,对高价值场景(护照检查)使用 ML-DSA

3. 向后兼容性

问题: 旧系统不理解 ML-DSA——会拒绝带有未知签名类型的凭证。

缓解措施:

  • 混合签名:同时用 Ed25519 + ML-DSA 双重签名(旧系统检查 Ed25519,新系统检查 ML-DSA)
  • 信任注册表标记:“签发者 X 使用 PQC” → 验证者知道要预期 ML-DSA
  • 渐进式推行:新签发者使用 PQC,旧签发者继续使用 Ed25519(5-10 年过渡期)

密码学敏捷性:为算法迁移做好准备

历史教训: 算法会出乎意料地被攻破(MD5、SHA-1、RSA-1024 都比计划提前被弃用)。

密码学敏捷性 = 在不破坏系统的前提下替换密码学算法的能力。

最佳实践

  1. 算法标识符:始终在凭证中包含算法类型:

    "proof": {
      "type": "Ed25519Signature2020", // 或 "Dilithium3Signature2024"
      "created": "2026-07-22T00:00:00Z",
      "proofPurpose": "assertionMethod",
      "verificationMethod": "did:webvh:company-x#key-1",
      "proofValue": "z3F..."
    }
  2. 多重验证方法:DID 文档支持多个密钥(Ed25519 + ML-DSA + SLH-DSA)。

  3. 信任注册表策略:“2030 年后只接受 PQC 签名”(集中强制执行,所有验证者都需遵守)。

  4. 签名套件:W3C 可验证凭证规范定义了签名套件——可插拔的密码学方案(无需更改凭证结构即可把 Ed25519 换成 ML-DSA)。

  5. 密钥轮换:定期轮换密钥(每 1-2 年)——若算法被攻破,只有近期的凭证受影响(而非 10 年的历史记录)。


后量子时间线

今天(2026 年)

  • NIST 标准已发布(FIPS 203、204、205)
  • 已有可用的库:liboqs(Open Quantum Safe)、PQClean、BoringSSL(Google)
  • 早期采用者:Affinidi、Signal(消息中的 PQC)、Google Chrome(TLS 中的 PQC)

近期(2027-2029 年)

  • 混合部署:Ed25519 + ML-DSA 双重签名成为默认方案
  • 硬件支持:ARM、Intel 增加 PQC 指令集(加速格运算)
  • 浏览器支持:Chrome、Firefox 原生验证 ML-DSA 签名

中期(2030-2035 年)

  • 仅限 PQC 的强制要求:政府数字身份项目要求使用 PQC(不再允许 Ed25519/ECDSA)
  • 量子计算机问世:CRQC(10,000+ 逻辑量子比特)攻破 RSA-2048、ECDSA-256
  • 旧算法被弃用:Ed25519/ECDSA 退出历史舞台(所有新凭证使用 ML-DSA)

长期(2035 年以后)

  • 后量子成为标准:ML-DSA 成为默认方案(就像 2000-2020 年间的 RSA)
  • 算法更新换代:若格密码学显现弱点,迁移至 SLH-DSA 或新一轮 NIST 标准
  • 抗量子生态系统:DID、可验证凭证、信任注册表全面兼容 PQC

Affinidi 的 PQC 集成

PQC 的应用位置:

  1. Elements Services:使用 ML-DSA 签名签发凭证
  2. DID 文档:支持 Dilithium3VerificationKey2024 类型
  3. 信任注册表:跟踪哪些签发者使用 PQC(为验证者提供标记)
  4. Agent Gateway:使用 ML-DSA 为智能体 Mandate 签名(抗量子的智能体身份)

示例凭证:

{
  "@context": ["https://www.w3.org/2018/credentials/v1"],
  "type": ["VerifiableCredential"],
  "issuer": "did:webvh:company-x",
  "issuanceDate": "2026-07-22T00:00:00Z",
  "credentialSubject": { "name": "Alice", "role": "Engineer" },
  "proof": {
    "type": "Dilithium3Signature2024",
    "created": "2026-07-22T00:00:00Z",
    "verificationMethod": "did:webvh:company-x#ml-dsa-key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z3F... (2,400 字节)"
  }
}

快速上手 PQC

体验后量子签名:

  • liboqs:开源 PQC 库(提供 C、Python、Go 绑定)
  • Affinidi SDK:Beta 版支持 ML-DSA 凭证签名
  • NIST PQC 参考实现:测试向量、参考代码

开始构建 →

文档:


相关资源

技术深度解析

相关解决方案


总结

后量子密码学(PQC) 保护可验证凭证免受量子计算机的攻击:

威胁所在:

  • 量子计算机(2030-2035 年)将攻破 RSA、ECDSA、Ed25519
  • “现在存储,未来解密”攻击会危及今天的凭证
  • 身份基础设施现在就需要抗量子签名

NIST 标准(2024 年):

  • ML-DSA(FIPS 204):基于格的签名,速度快,签名约 2.4 KB
  • SLH-DSA(FIPS 205):基于哈希的签名,保守稳妥,签名约 7-50 KB

建议:

  • 使用 ML-DSA-65(主选)——速度快、抗量子、体积合理
  • 使用 SLH-DSA(备用)——若格假设失效时的保守兜底方案
  • 使用混合方案(Ed25519 + ML-DSA)——迁移期间保持向后兼容

面临的挑战:

  • ⚠ 签名体积大(比 Ed25519 大 40 倍)
  • ⚠ 验证开销大(慢 5 倍)
  • ⚠ 向后兼容性问题(旧系统不理解 ML-DSA)

缓解措施:

  • 密码学敏捷性(支持多种签名套件)
  • 混合签名(同时使用 Ed25519 + ML-DSA 双重签名)
  • 硬件加速(ARM/Intel 即将推出的 PQC 指令集)

Affinidi 使用 PQC 的场景:

  • Elements Services(ML-DSA 凭证签名)
  • DID 文档(Dilithium3VerificationKey2024)
  • 信任注册表(跟踪 PQC 采用情况)
  • Agent Gateway(抗量子的智能体 Mandate)

结果: 即便量子计算机攻破了经典密码学,可验证凭证依然保持安全——面向未来的身份基础设施。

Cookie Preferences

We use cookies to enhance your experience. You can manage your preferences below. For more information, read our Cookie Policy.

Strictly Necessary Always Active

These cookies are essential for core website functions such as security, session integrity, and cookie preference storage. They cannot be disabled.

  • _cf_bm: Distinguishes humans from bots (Cloudflare) · 30m
  • _cfuvid: Ensures secure browsing (Cloudflare) · Session
  • __hs_initial_opt_in: Prevents HubSpot's banner · 7 days
  • _gtm_debug: GTM debug mode (testing only) · Session
Analytics

These cookies help us understand how visitors interact with the site so we can improve content and performance. All data is aggregated and anonymous.

  • _ga, _gid, _gat: Google Analytics · Session – 2 years
  • __hstc, hubspotutk, __hssrc: HubSpot visitor tracking · 13 months
  • __hs_opt_out: HubSpot opt-out preference · 6 months
Marketing & Targeting

These cookies allow us and our partners to serve personalised ads and measure campaign performance.

  • _gcl_au, _gcl_dc: Google Ads conversion tracking · 90 days
  • IDE: Google Display Network personalisation · 1 year
  • _fbp: Meta / Facebook remarketing · 90 days
  • li_gc, _li_fat_id, bcookie: LinkedIn tracking · 1–24 months
  • guest_id, personalization_id: Twitter/X analytics · 2 years