本节摘要:SOURCE 2.2 与 2.4:McEliece 等编码方案历史悠久;SPHINCS+ 基于哈希无状态签名。本节对比「大公钥小密文」与「大签名慢验证」的权衡。
| 方案 | 特点 | 部署注意 |
|---|---|---|
| Classic McEliece | 公钥 ~MB 级 | 适合静态 KEM |
| BIKE/HQC | 中等尺寸 | NIST 第四轮备选 |
优势:研究历史长(1978 McEliece);劣势:公钥极大,TLS 握手不友好。
| 对比 | Dilithium | SPHINCS+ |
|---|---|---|
| 假设 | 格 | 哈希 |
| 签名大小 | ~2.4 KB | ~17 KB |
| 速度 | 快 | 慢 |
⚠️ 常见坑:在 IoT 实时握手用 SPHINCS+——延迟与带宽可能不可接受。
💡 关键直觉:哈希路线是「保守派」备份;格路线是「性能派」主力。
Classic McEliece 的历史可以追溯到 1978 年,它基于一般的编码理论问题:给定一个含随机错误掩盖的线性码,恢复原始明文在计算上被普遍认为困难。它的公钥是二进制 Goppa 码的生成矩阵,尺寸达到几百 KB 甚至 MB 级,但密文非常小、加解密速度快、安全分析经受了几十年检验。这种「大公钥、小密文、高速率」的组合让它在静态场景大放异彩,比如邮件加密、批量密钥分发;而在每毫秒都要做一次握手的 Web 服务端,光公钥传输就足以让 TLS 握手明显变慢,这是它没能进入首批 TLS 主流的主要原因。
SPHINCS+ 走的是完全相反的路。它的安全性只依赖哈希函数的标准性质,几乎不依赖任何新的数论假设,因此被称为「最保守」的 PQC 签名。代价是签名体积大、签名与验证都要做大量哈希运算,性能明显落后于格方案。但它有一个独特的价值:在哈希函数被广泛信任、而格假设可能出现意外突破的长期视角下,它提供了几乎不可能被结构性攻破的兜底。
# 编码 vs 哈希两条路线的取舍清单 维度 Classic McEliece SPHINCS+ 数学假设 一般线性码译码困难 哈希函数抗碰撞 公钥尺寸 数百 KB ~ MB 仅 32 B 密文/签名 小(KB 内) 签名 ~17 KB 加解密速度 快 慢 典型场景 静态密钥封装 长期归档签名、根密钥 风险来源 公钥传输带宽 签名体积与性能
实际工程中这两条路线不是二选一,而是可以组合:日常流量用格方案保证性能,归档与根信任锚用哈希方案保证长期稳健。理解「什么场景容忍大密钥」「什么场景容忍大签名」,比单纯记住尺寸数字更重要,这正是本节的实用价值所在。
长期归档对签名的要求与在线握手完全不同,最核心的诉求是「几十年后仍可验证」。这带来两个工程问题:一是签名算法与参数集的长期可用性,二是验证方的工具链在几十年后是否还能处理这种格式。SPHINCS+ 依赖的哈希函数是当前最被广泛信任的原语,但归档系统通常还要额外保存算法标识、参数集与生成工具版本,防止「算法还在、工具没了」。
归档签名还有一个被低估的细节是密钥丢失风险。哈希签名方案的公钥极小、签名大,私钥的安全性完全依赖随机种子与密钥管理流程。归档数据的签名密钥一旦丢失,等于所有归档文件失去完整性证明。因此归档场景通常把签名私钥放在离线 HSM 或分级密钥管理中,并保留多副本,这与 McEliece 的「大公钥、小密文」形成了有趣的互补:一个怕公钥传不动,一个怕私钥丢不起。
# 归档签名体系设计清单 1. 确定归档期限(20 年 / 50 年)决定算法与参数集 2. 签名私钥存入离线 HSM,保留多副本并定期测试恢复 3. 记录算法名、参数集、生成工具版本与官方参考实现 4. 同时保存 SHA-256 摘要作为第二层完整性校验 5. 定期(如每 5 年)重新签名验证旧签名仍可校验 6. 评估是否需要叠加混合签名(格 + 哈希双签名) 7. 归档格式选择开放标准,避免绑定单一厂商实现
这套清单的核心理念是把「长期可验证」当成一个持续过程,而不是一次性签名动作。归档系统每五年做一次重签演练,既能发现工具链退化,也能在算法演进时及时补签,让数据的完整性证明跟随密码学发展而不是原地停滞。