QianHeng乾珩 PQC Docs Hub量子文档 ✦ Ask AI✦ 问问文档 ⚐ Scan⚐ 扫一扫
/

SP 800-208 — Stateful Hash-Based Signatures

NIST Special Publication 800-208 (2020) approves two families of stateful hash-based signature schemes — LMS/HSS and XMSS/XMSS^MT — for use ahead of the main PQC standards. They are ideal for firmware and software signing, but carry a critical state-management hazard.

What SP 800-208 approves

Published in October 2020, well before the FIPS 203/204/205 trio, SP 800-208 was NIST's first formal blessing of a quantum-resistant signature scheme. It approves:

  • LMS (Leighton-Micali Signatures) and HSS (Hierarchical Signature System) — a multi-tree generalization of LMS, specified in RFC 8554.
  • XMSS (eXtended Merkle Signature Scheme) and XMSS^MT (multi-tree XMSS), specified in RFC 8391.

Like SLH-DSA, these rest only on hash-function security — making them extremely conservative. Unlike SLH-DSA, they are stateful.

The state-management hazard

Each of these schemes is a Merkle tree of one-time signature (OTS) keys. Each leaf may be used to sign exactly once. The signer must track which leaf indices have been consumed and never reuse one.

Warning
Reusing a one-time-key index is catastrophic: it can allow an attacker to forge signatures, completely breaking the scheme. State reuse can happen through VM snapshots/rollbacks, restoring from backup, cloning a signing appliance, crashes between signing and persisting state, or running the same key on multiple hosts. Treat the state as the most sensitive object in the system.

Mitigations SP 800-208 emphasizes:

  • Persist the updated state first, then perform the signature and release the result (persist-then-sign-then-release ordering).
  • Use hardware-backed key storage (HSM) that enforces monotonic index advancement.
  • Never clone, snapshot, or back up the private state in a way that could resurrect a used index.
  • Prefer hierarchical variants (HSS, XMSS^MT) to manage huge signature capacities without an impractically large single tree.

Parameter overview

SchemeSpecHashStructureCapacity per tree
LMSRFC 8554SHA-256Single Merkle tree of LM-OTS2^h leaves (h up to 25)
HSSRFC 8554SHA-256Multi-level tree of LMSProduct of per-level heights
XMSSRFC 8391SHA-256/SHAKESingle Merkle tree of WOTS+2^h leaves
XMSS^MTRFC 8391SHA-256/SHAKEHypertree of XMSSProduct across layers

The ideal use case: firmware and boot signing

Stateful hash-based signatures shine for firmware, secure-boot, and software-update signing:

  • Signing happens in a controlled environment (a release pipeline or HSM), where strict state management is feasible.
  • The verifier (boot ROM, bootloader) only needs a small hash-based public key and verification logic — no lattice math, low gate count.
  • The conservative hash-only security matches the decades-long lifetime of deployed firmware.

For general-purpose, high-volume, or hard-to-control signing environments, prefer the stateless SLH-DSA or the lattice-based ML-DSA, which avoid the state hazard entirely.

Note
SP 800-208 schemes were standardized early precisely so that firmware signed today can be verified securely for decades — addressing harvest-now-sign-later concerns for long-lived devices. But only deploy them where you can absolutely guarantee no index is ever reused.

XMSS & LMS deep dive →

Construction details and state handling.

FIPS 205 — SLH-DSA →

The stateless alternative.

Hash-based family →

How these schemes relate.

Standards & references

SP 800-208 有状态哈希签名

NIST 特别出版物 800-208（2020 年）批准了两类有状态哈希签名方案 LMS/HSS 与 XMSS/XMSS^MT 供主力后量子标准发布之前使用。它们非常适合固件与软件签名，但带有一项关键的状态管理隐患。

SP 800-208 批准了什么

该文档于 2020 年 10 月发布，远早于 FIPS 203/204/205 三件套，是 NIST 对抗量子签名方案的首次正式认可。它批准了：

  • LMS Leighton-Micali 签名与 HSS 分层签名系统，后者是 LMS 的多树推广，规范见 RFC 8554。
  • XMSS 扩展 Merkle 签名方案与 XMSS^MT 多树 XMSS，规范见 RFC 8391。

与 SLH-DSA 一样，它们仅依赖哈希函数安全，因而极为保守。但与 SLH-DSA 不同，它们是有状态的。

状态管理隐患

这些方案本质上都是一次性签名（OTS）密钥构成的 Merkle 树。每个叶节点只能用于签名恰好一次。签名方必须跟踪哪些叶索引已被消耗，并绝不重用。

警告
重用一次性密钥索引是灾难性的，可能让攻击者伪造签名、彻底攻破方案。状态重用可能由多种情形引发：虚拟机快照或回滚、从备份恢复、克隆签名设备、签名与持久化状态之间发生崩溃，或在多台主机上运行同一密钥。请将状态视为系统中最敏感的对象。

SP 800-208 强调的缓解措施：

  • 在释放每个签名之前，先持久化更新后的状态，再执行签名并释放签名结果。
  • 使用硬件支撑的密钥存储（HSM），强制索引单调递增。
  • 绝不以可能复活已用索引的方式克隆、快照或备份私有状态。
  • 优先采用分层变体 HSS 与 XMSS^MT，以管理庞大签名容量，而无需不切实际的超大单树。

参数概览

方案规范哈希结构单树容量
LMSRFC 8554SHA-256LM-OTS 的单 Merkle 树2^h 叶（h 至 25）
HSSRFC 8554SHA-256LMS 的多层树各层高度之积
XMSSRFC 8391SHA-256/SHAKEWOTS+ 的单 Merkle 树2^h 叶
XMSS^MTRFC 8391SHA-256/SHAKEXMSS 的超树跨层之积

理想场景固件与启动签名

有状态哈希签名在固件安全启动与软件更新签名中大放异彩：

  • 签名发生在受控环境（发布流水线或 HSM）中，严格的状态管理切实可行。
  • 验证方（启动 ROM 或引导加载器）只需一个小的哈希公钥与验证逻辑，无需格运算，门数极低。
  • 仅依赖哈希的保守安全，与已部署固件长达数十年的生命周期相匹配。

对于通用大批量或难以管控的签名环境请优先选用无状态的 SLH-DSA 或基于格的 ML-DSA，它们完全规避了状态隐患。

注意
SP 800-208 方案之所以提早标准化，正是为了让今天签名的固件在数十年内仍可安全验证，以应对长生命周期设备面临的先收集后签名担忧。但务必只在你能绝对保证索引永不重用的场景中部署。

XMSS 与 LMS 深入 →

构造细节与状态处理。

FIPS 205 SLH-DSA →

无状态替代方案。

哈希签名家族 →

各方案的关系。

标准与参考

⚑ Report an error⚑ 纠错与校正