2.2 基于编码与哈希


2.2 基于编码与哈希

本节摘要:SOURCE 2.2 与 2.4:McEliece 等编码方案历史悠久;SPHINCS+ 基于哈希无状态签名。本节对比「大公钥小密文」与「大签名慢验证」的权衡。

核心问题

  1. 说明 Classic McEliece 的尺寸特点
  2. 解释 SPHINCS+ 仅依赖哈希函数的安全假设
  3. 为长期归档签名选哈希路线

一、编码密码(SOURCE 2.2)

方案 特点 部署注意
Classic McEliece 公钥 ~MB 级 适合静态 KEM
BIKE/HQC 中等尺寸 NIST 第四轮备选

优势:研究历史长(1978 McEliece);劣势:公钥极大,TLS 握手不友好。

二、哈希签名 SPHINCS+(SOURCE 2.4)

  • 无状态 — 不需维护签名状态树(对比 XMSS 有状态)
  • 假设弱 — 仅依赖哈希函数抗碰撞
  • 代价 — 签名 ~17KB(参数相关),生成/验证较慢
对比 Dilithium SPHINCS+
假设 哈希
签名大小 ~2.4 KB ~17 KB
速度

⚠️ 常见坑:在 IoT 实时握手用 SPHINCS+——延迟与带宽可能不可接受。

💡 关键直觉:哈希路线是「保守派」备份;格路线是「性能派」主力。

本章回顾

  • McEliece:老方案、大公钥
  • SPHINCS+:哈希假设、大签名、适合归档
  • 与 Kyber/Dilithium 形成性能/假设对照

深入讨论:编码方案与哈希签名的适用边界

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. 归档格式选择开放标准,避免绑定单一厂商实现

这套清单的核心理念是把「长期可验证」当成一个持续过程,而不是一次性签名动作。归档系统每五年做一次重签演练,既能发现工具链退化,也能在算法演进时及时补签,让数据的完整性证明跟随密码学发展而不是原地停滞。


作者与出处
原作者: 灏天文库
来源:灏天文库
整理: 灏天文库整理
由灏天文库平台收录,内容或由平台用户上传,仅供学习交流
发布者: 作者: 灏天文库 转发
评论区 (0)
U