2. 哈希签名基础与SLH-DSA定位

要理解SLH-DSA，必须先回到哈希签名的两条基本支柱：一次性签名（OTS）和Merkle树。哈希签名的安全性只依赖哈希函数的抗碰撞性与单向性，不依赖大整数分解或离散对数等数论难题，因此被视为后量子时代最保守、最容易论证的一类签名方案。代价是：单个一次性密钥只能安全地签一条消息，一旦重复使用，私钥信息就会泄露。如何把"一次性"扩展成"多次可用"，正是各类哈希签名方案的分水岭。

一次性签名：签名的原子单元

以最经典的Lamport方案为例，私钥是两组随机数，每组长度等于哈希输出位数。签名时，根据消息摘要的每一位选择揭示对应位置的私钥元素；验证方对揭示值做哈希，与公钥中对应位置比对。若摘要为 n 位，则私钥含 2n 个随机值，公钥为它们的哈希，签名长度约 n 个元素。Winternitz OTS（WOTS/WOTS+）通过"链式哈希"把多个比特压缩进一个链值，用更长的计算换取更短的签名，是SPHINCS+与SLH-DSA实际采用的构件。关键约束始终不变：同一密钥对签两条不同消息，攻击者即可拼凑出伪造签名。

Merkle树：把一次性密钥组织成可认证集合

Merkle树把 2^h 个OTS公钥作为叶子，逐层哈希得到根，根即为"全局公钥"。签名某叶子时，附上从该叶到根的认证路径（h 个兄弟节点哈希），验证方重算根并与公开根比对。这样一棵高度为 h 的树可支持 2^h 次签名，但每签一次就消耗一个叶子，且需要记录"已用到第几个叶子"的状态。

这正是LMS与XMSS的核心思路：有状态哈希签名。它们性能好、签名短，但状态管理是工程负担——多副本部署、备份回滚、并发签名都可能导致叶子复用，从而彻底破坏安全性。XMSS还引入了比特翻转树等改进以支持更高效的认证路径更新，并已成为RFC 8391标准；LMS则由RFC 8554定义。二者都要求签名者严格维护单调递增的索引。

SPHINCS+与SLH-DSA：走向无状态

SPHINCS+用两层结构消除状态：底层是若干棵L-tree（由WOTS+密钥经Merkle树压缩成"少次签名"密钥），上层是超树（hypertree），由多层子树堆叠，使总高度可达数十层，从而用少量叶子覆盖海量签名次数。签名时不再顺序消耗叶子，而是用消息哈希与随机化种子伪随机选取一条从顶层根到最底层WOTS+密钥的路径，再沿路径逐层生成认证路径。由于选择是伪随机的，同一密钥可反复使用而不泄露秘密，代价是签名体积显著增大（典型参数下数KB到数十KB）和签名时间上升。

SLH-DSA即FIPS 205标准化的SPHINCS+版本，是NIST后量子标准化进程中唯一的无状态哈希签名标准。它提供纯哈希与基于SHAKE的两种实例族，并按安全级别与签名速度/体积权衡给出多组参数集（如128位安全级别的s/f两档）。其定位可以概括为：安全假设最保守、实现最简单、但签名最大、速度较慢的"兜底型"后量子签名。相较之下，ML-DSA（基于格的Dilithium）签名小、速度快，是通用场景首选；SLH-DSA则适合对安全假设极度敏感、或需要算法多样性的场景，例如固件签名、根证书、长期归档签名。

关系与差异的横向对照

把四类方案放在同一张表里，差异会更清晰。下表参数为典型量级示意，用于建立直觉，具体数值以各标准参数集为准。

工程视角下的取舍

选择SLH-DSA时，最需要提前评估的是签名体积对协议的影响。例如在证书链中，若一张证书携带数十KB的SLH-DSA签名，握手报文可能超出单个UDP数据报或硬件缓冲区上限，需要分片或改用更大MTU的传输。其次是验签耗时：SLH-DSA验签需重建超树路径上的多棵子树，计算量明显高于ML-DSA，在低功耗MCU上应实测而非估算。第三是参数集选择：同一安全级别下，"s"（small）档签名更短但更慢，"f"（fast）档更快但签名更大，需按设备算力与带宽权衡。

综上，SLH-DSA并非要取代ML-DSA，而是在后量子签名体系中承担"安全假设最简、部署最省心"的一极。理解它与LMS、XMSS、SPHINCS+的继承与分野，是后续实现与评估工作的前提：实现层面要复用WOTS+与超树的构件逻辑，评估层面则要围绕体积、速度与参数集展开量化比较。