SHRINCS抗量子签名草案挑战：状态管理与多设备同步难题

抗量子签名草案SHRINCS提出通过记录钱包已使用的签名位置来压缩签名数据，但这一机制为钱包实现带来双重挑战：一是恢复助记词后如何确保签名安全性；二是多设备环境下状态同步的可行性。

Decrypt于当地时间12日报道了Treasure CTO Tomáš Sušánka的观点，他指出：“状态追踪不应成为用户的负担。” 这一立场凸显了用户友好性在抗量子方案落地中的关键作用。

小尺寸签名依赖钱包状态维护

SHRINCS结合了状态型与无状态型基于哈希的签名机制。状态型签名需记录已使用的位置，签名大小在548至4619字节之间；而无状态型签名无需状态记忆，但固定为5777字节。

此前报道已揭示该草案在签名尺寸与状态恢复结构上的权衡。若同一计数器被重复使用，攻击者可能利用两个签名构造出伪造签名。计数器是防止重复使用的核心机制。

为此，提案建议禁止从备份中恢复计数器，也不允许跨软件迁移。同时，应避免并发签名操作。一旦发现恢复后的计数器不可信，则应立即切换至无状态路径，停止使用状态型签名。

当多个设备共享相同助记词时，状态偏差将导致重复签名风险。因此，必须同步设计恢复流程与设备间的状态同步机制。

Sušánka表示，Treasure正考虑将不追踪状态的无状态签名设为默认选项，而将更紧凑的状态型签名作为高级功能。此举旨在避免将状态管理责任转嫁给普通用户。

在9月1日的比特币开发者邮件列表中，Antoine Riard提出疑问：为应对Lightning Network等链下交易的复制问题，是否需要采用无状态签名？并询问5777字节签名对运营成本的影响。

提案方回应称，签名大小与实际手续费增加并非线性关系。签名数据体积并不直接等同于链上费用增长，需综合考虑区块空间占用与矿工行为。

算法标准与设备安全分属不同层面

美国国家标准与技术研究院（NIST）已于2024年将无状态型基于哈希的SLH-DSA纳入FIPS 205标准。尽管SHRINCS的无状态组件也基于此算法，但其参数配置与标准存在差异。

目前，SHRINCS仍处于草案阶段，尚未分配BIP编号。其安全性证明、完整测试向量及高效实现均未完成。文档明确警告：示例代码不得用于生产环境。

Treasure官方说明指出，Safe 7启动过程中使用SLH-DSA-128验证引导加载程序，设备证书则采用ML-DSA-44。待这些功能全面集成至固件与Trezor Suite后，将提供额外硬件安全保障。

然而，此类机制仅覆盖设备启动过程与真伪验证，并不自动赋予比特币交易签名抗量子能力。要真正实现网络层面的抗量子性，还需达成共识规则更新。

此前，七国政府曾呼吁加速向后量子密码学过渡。但SHRINCS草案仍未包含适用于比特币网络的共识变更机制或具体实施时间表，表明其距离实际部署仍有显著距离。