摘要

  • RFC 9858 登记了新的 SHA-256 与 SHAKE256 参数组合，让验证器知道如何解释签名；它没有记录私钥状态如何被保管。
  • 单份签名可以完全有效，同时另一进程、另一机房或恢复后的快照又从同一个叶子编号开始签名。
  • 真正的控制点是：签名离开设备前先持久化状态、杜绝可同时激活的私钥副本、监测有限容量，并提前完成继任公钥切换。

验证器看得到 q，却看不到另一个机房

RFC 9858 于 2025 年 10 月由 IRTF 的 Crypto Forum Research Group 发布。它为 HSS/LMS 增加 SHA-256 的 192 位输出组合，以及 SHAKE256 的 192 位与 256 位输出组合；相应的 LM-OTS、LMS 标识已经进入 IANA 登记表。实现看到类型码，便能确定哈希函数、输出长度、树高和 Winternitz 参数，彼此不必猜测。

这解决的是密码语法，不是托管历史。

LMS 每签一次，就消耗默克尔树中编号为 q 的一片叶子。叶子背后是一次性密钥，因此私钥不只是一串静态秘密，还包含不断前进且容量有限的状态。RFC 8554 明确警告，重复使用私钥状态可能摧毁方案的安全保证。

但验证器拿到的只是消息、签名、公钥和认证路径。它可以重算树根，判断眼前的组合是否相符。它看不到签名服务是否还有第二个实例，不知道一次数据库事务是否在导出签名后才写入，也不知道灾备系统下周是否会恢复一份更旧的快照。一次 VALID 只能证明这份签名成立，不能证明世界上不存在另一个相同的 q。

因此需要两套证据。参数证据回答用了哪一种哈希、输出长度、树高和计算配置；状态证据回答谁拥有可变状态、何时预留、何时落入非易失存储、何时对外释放，以及还有哪些副本能够继续签名。RFC 9858 扩展了前者的选择，并未替后者背书。

192 位组合确实带来工程权衡：与 256 位输出组合相比，密钥与签名材料更小，但安全余量也较低。SHAKE256 可能更适配某些平台已有的原语。然而采购文件只写“支持 RFC 9858”仍远远不够；它没有说明选中了哪个登记组合、为何适合预期密码周期，也没有说明断电与并发时计数器怎样存活。

NIST SP 800-208 把这层运行要求写得很具体。在合规的硬件模块生成场景中，私钥材料不可导出。更关键的是，设备必须在导出签名或接受下一项请求之前，先增加叶子索引并把新状态写入非易失存储。顺序本身就是安全属性。普通文件写入可能只到缓存；如果先交付签名、后落盘，掉电便可能把设备带回已经使用过的叶子。

所以恢复不是“把备份拷回去”。可以在 HSS 层级下使用相互独立的树，为不同签名域分配不重叠范围，或准备全新的继任密钥。不能把同一份可变私钥复制到两处，再期望验证器替托管系统识别重复。可用性设计若缺少唯一所有权，恰好会制造一次性秘密的并发使用。

树高还规定了总预算。重试、保守预留、失败释放都会消耗叶子，外部看见的签名数量未必等于内部消耗。运营方必须掌握可信的持久化高水位、最大预留值、实际释放值与剩余容量，并在阈值到来前完成继任公钥分发。两份冲突签名一旦从同一叶子流出，之后再对账也无法让风险消失。

资料来源