撰文:Blockstream Team
编译:Saoirse,Foresight News
Blockstream 研究院发布了一份针对比特币格基签名的完整研究报告。本文对研究内容、核心发现以及相关建议进行总结,完整报告可点击查阅。
数字签名是比特币授权交易的核心机制,如今承担该功能的 Schnorr 与 ECDSA 签名成本极低。1994 年 Shor 证明,一台性能足够强大的量子计算机就可以破解这两类签名。虽然这类机器何时能够问世仍存在广泛讨论,但我们需要在问题真正到来之前,就制定一套可行的后量子签名部署方案。
格基签名方案是替代现有签名的热门候选。格密码已有超过一个世纪的研究历史,其密码学应用也发展了近三十年。在后量子密码体系中,格基签名具备诸多优势:公钥与签名的总尺寸最低可小于 1.6 千字节,同时其代数结构未来有希望支持多签、门限签名以及简洁证明。
本报告研究了 Dilithium、Falcon、Hawk 三种方案。面向不了解格密码的读者,我们阐述各方案的设计思路,完整介绍算法流程,并从安全性、性能、实际部署(例如钱包密钥派生)等维度展开分析。三者之中,究竟哪些方案可以真正部署到比特币链上?
评估维度
比特币对签名方案的选型有着自身约束,本次评估围绕四项核心标准展开:
- 链上成本:最重要指标之一为公钥与签名的总大小。输出被花费时,公钥和签名都会记录在链上,全节点需要下载并存储每一个字节。验证开销同样关键:每一笔签名都要经过全网节点验证,验证速度慢会给整个网络带来负担。
- 实现复杂度:方案能否安全实现至关重要。如果设计需要浮点运算或者精细的高斯采样,一旦实现出错,或是遭遇计时分析这类侧信道攻击,就可能泄露密钥。想要实现平稳迁移,实现复杂度是不可忽视的因素。
- 部署风险:比特币实际集成时还会遇到各类现实阻碍:共识层面的哈希函数选型(候选方案大多使用 SHAKE,比特币使用 SHA‐256)、跨平台签名结果的可复现性,以及签名程序是否适配硬件钱包的内存限制。
- 发展潜力:绝大多数比特币钱包采用 BIP‐32 分层确定性机制:通过单个主公钥,无需接触私钥,就可以衍生出无穷多子公钥。目前标准化的后量子签名方案都不原生支持该特性,因此我们研究为其补充该能力所要付出的代价;同时也考察各类非标准的方案变体,它们或许能带来更多收益。
应当选择何种安全等级?
对比尺寸之前,先要确定目标安全等级,该选择并没有看上去那么简单。NIST 将安全等级划分为 1‐5 级;等级越高安全性越强,但对应的密钥与签名体积也会更大。
我们认为比特币至少应当采用 3 级安全标准。比特币输出可能数十年不被花费,如果密码分析技术进步导致方案实际安全等级下降,资产就会被削弱后的密钥锁定,长期暴露在风险之下。格密码假设已经经受了近三十年公开密码分析,对比特币采纳椭圆曲线时的研究积淀还要更久。但格密码复杂的代数结构,仍存在不少可供未来攻击利用的突破口,我们不应当把遥远未来的安全赌注全部押在上面。
各大主流产品也做出了相同判断。苹果的 iMessage PQ3 协议直接舍弃 1 级格密码参数,全程使用 3 级与 5 级参数;Cloudflare 在后量子 TLS 部署中使用 ML‐KEM‐768(3 级),表示虽然 1 级目前看起来安全,但需要为未来数十年的密码分析预留安全余量。而比特币的安全时间跨度比以上两者还要更长。
提升安全等级是需要付出代价的。举例来说,Dilithium 从 2 级提升至 3 级,总大小会增加约 1.5 千字节。报告对比了全部安全等级下的参数集,读者可以自行权衡取舍。Hawk 的遭遇证明,保守的安全考量绝非纸上谈兵。
候选方案详解
Dilithium:设计简洁的方案
Dilithium 被 NIST 标准化为 FIPS 204 标准中的 ML‐DSA,它将 Schnorr 签名的承诺‐挑战‐响应范式,迁移到模块格算术之上。
它最大的特点是简洁。Dilithium 全部运算均为整数运算:环运算、矩阵向量乘法、哈希、取整,没有浮点运算,也不需要离散高斯采样。更容易编写出安全、恒定时间的实现。它也是落地最广泛的候选方案,已经集成进 OpenSSL、BoringSSL、AWS‐LC 以及 Apple CryptoKit。
代价是体积偏大。3 级安全的 ML‐DSA‐65,公钥 1952 字节,签名 3309 字节,合计 5261 字节,约为比特币原生公私钥 + 签名总大小的 55 倍,在同安全等级的三个方案中体积最大。
对比特币而言 Dilithium 最有价值的一点:它是三者中唯一一个接近实现 BIP‐32 风格密钥派生的方案。可重随机化密钥构造 DilithiumRK,仅依靠公开信息就可以由父密钥生成子密钥。报告分析了三种变体,其中包含我们提出的 DilithiumRKS,派生逻辑完全放在钱包软件内部,链上只需要标准验证器处理普通 ML‐DSA 签名。但三者均尚未达到上线标准:其中两种变体需要修改验证器,DilithiumRKS 本身还缺少完整的不可伪造性证明;全部方案都依赖全网共用的矩阵,虽然在 Module‐LWE 假设下形式上安全,但会把所有密钥的安全绑定到同一个实例上。我们认为现阶段基于 Dilithium 的公钥派生仅属于概念验证,无法投入实际部署。
Falcon:体积紧凑的方案
Falcon 被 NIST 选定,标准化名称为 FN‐DSA,三者之中它最为精简。1 级安全的 Falcon‐512 公钥加签名合计 1563 字节;5 级安全的 Falcon‐1024 合计 3073 字节。安全余量更高的 Falcon‐1024,体积甚至小于 3 级的 Dilithium。
Falcon 采用与 Dilithium 不同的思路:基于 NTRU 格的哈希‐签名模式。签名者的私钥是格的一组短基;消息被哈希映射到空间中的一个点,签名者利用短基找到格上距离该点很近的向量。点与该邻近向量共同构成签名;验证仅校验向量属于该格,并且距离足够近。实现难点在于寻找向量的同时不能泄露基的信息。早期方案 GGH、NTRUSign 直接就近取格点,每一次签名都会泄露一部分几何信息。Falcon 采用 GPV 框架,从高斯分布中采样邻近向量,可证明采样输出与基相互独立,消除泄露风险,但采样器的实现难度大幅提升。
采样器是 Falcon 工程层面的短板。它在复数傅里叶域运算,需要浮点计算。不同处理器、编译器、编译优化选项,都会造成浮点输出结果不一致。这不只是兼容性问题,更是安全隐患:GPV 安全证明要求,对同一摘要,签名者绝不输出两组不同的短向量;一旦签名变为确定性签名,平台带来的浮点舍入差异就会破坏该条件。存在可行的解决办法:确定性 Falcon 可以用整数模拟替代硬件浮点,在所有平台输出完全一致的签名。代价是签名速度下降约 15 倍,密钥生成速度下降约 2 倍。
重要的是,验证环节不受影响:Falcon 验证全程整数运算、结果确定,同时也是候选方案中验证速度最快的。这种非对称特性对比特币十分友好:签名由钱包在花费交易时执行一次,而每一笔签名都要被全网全节点验证。签名环节慢 15 倍属于低频开销,换来跨平台可复现、整数运算,在我们看来是合理取舍。因此浮点问题属于可以通过工程手段解决的障碍,而非致命缺陷。
两点注意事项:受结构约束,Falcon 没有 3 级参数,只能选择 1 级或者 5 级。基于安全余量考量,我们推荐 Falcon‐1024。第二点,签名会消耗大量内存:1024 参数集的采样器依赖预计算树,占用约 90 千字节内存。硬件钱包可以逐分支动态重建该树,把内存占用压缩至 16 千字节,但签名耗时会翻倍。硬件设备签名变慢是实际成本,但尚可接受。
Hawk:宣告失败的方案
Hawk 的目标是融合另外两套方案的优势:Hawk‐512 签名仅有 555 字节,比 Falcon 体积更小;签名端全部整数运算,最低内存占用仅 6 千字节。它也是 NIST 附加签名竞赛第三轮中唯一留存的格基候选,报告中用大量篇幅介绍该方案。
代价在于安全假设。它没有沿用经过数十年密码分析检验的 NTRU、SIS 问题,而是依赖格同构问题以及 one‐more‐SVP 假设,这两类假设研究历史相对较短。
就在报告定稿前夕,Anthropic 的 Straznickas 和 Weis 发现 Hawk 格构造存在结构性缺陷:密钥恢复实际需要求解的 SVP 问题维度,只有设计者设想的一半。候选参数集的密钥恢复安全位被大幅削弱。研究者针对用于密码分析的挑战参数 HAWK‐256 完成完整端到端密钥恢复攻击;即便遭受攻击,正式提案的 HAWK‐512、HAWK‐1024 依旧无法被现实攻破。Hawk 团队确认攻击有效,并将方案从 NIST 流程撤回;团队表示,如果通过翻倍参数修复漏洞,Hawk 原本引以为傲的体积优势就会彻底消失。
报告依旧保留 Hawk 相关章节,因为该攻击针对特定数域的代数特性,并非全盘否定这套设计范式。重新设计是否能够规避漏洞,尚无定论。Hawk 事件也直观印证了我们坚持保守安全余量的理由:一个方案即便体积优秀、速度可观,并且走完标准化多轮流程,一篇论文就可以使其预估安全等级大幅下降。
各方案对照表
上表所有方案(包括 SPHINCS+)均为无状态签名:签名者无需记录过往签名。XMSS 这类有状态哈希签名可以做到签名尺寸更小,但需要维护签名状态;可查阅哈希基签名专题报告了解对比。
落地仍存诸多阻碍
Falcon 缺少可用的密钥派生方案。目前公开唯一一套 BIP‐32 风格 Falcon 派生方案,会对私钥基做重随机化,签名范数上限被急剧放大,链上签名膨胀至约 23.7 千字节。并且该方案的参数达不到自身安全条件,如果修复该问题,体积会进一步暴涨。目前没有可行的 Falcon 公钥派生实现,也是报告提出最有价值的待解决问题。
Falcon 标准尚未定稿。NIST 虽然选定 Falcon,但 FN‐DSA 草案还未正式发布。标准化完成之后,才会带来经过审计的实现、测试向量与硬件层面支持。广泛落地能够降低比特币共识层集成的风险与难度。我们建议等待 FN‐DSA 正式发布,在此之前 Falcon 仍处于变动状态。
Falcon‐WS 变体:该变体放宽内部参数,依靠拒绝采样做补偿,1 级总大小压缩至 1114 字节,5 级压缩至 2387 字节,相比原版 Falcon 体积进一步下降。该方向具备研究价值,但不会纳入官方标准,需要更多密码分析验证。已有研究发现其衍生方案的强不可伪造性证明存在漏洞(普通不可伪造性不受影响)。
未来是否会出现更优秀的方案?除去上述方案,Fiat‐Shamir 系列最早源自 2013 年的 BLISS,CRYPTO 2025 会议 Gärtner 提出的最新成果,基于成熟假设,纸面尺寸可以比肩 Falcon。该系列难以工程落地的根源在于实现安全问题:BLISS 就曾因为高斯采样非恒定时间遭到侧信道破解;后续方案均没有彻底解决该隐患,最新成果也提示采样环节防护难度更高。在问题解决之前,这类方案只具备理论吸引力,不适合部署。
格基签名与哈希签名可以互补。格基签名可以作为混合方案的组件。例如 SHRINCS 中,无状态恢复路径目前使用数 KB 大小的 SPHINCS + 签名;替换为 Falcon(或 Falcon‐WS)签名,体积更小、验证更快,低频的恢复路径开销大幅降低,日常使用路径不受影响。
研究结论
格基候选方案的优劣排序十分明确:Hawk 遭 Anthropic 团队攻击后退出竞争;Dilithium 实现难度最低,也是唯一拥有密钥派生相关研究基础的方案,但体积对于比特币链上开销并不友好;Falcon 兼顾紧凑体积、快速验证、成熟安全假设;它最主要的短板 —— 签名端浮点运算,已经存在可行的工程解决方案。如果现在必须为比特币挑选格基签名方案,我们会选择 Falcon‐1024。
就当下而言,我们的观点与哈希基签名报告保持一致:短期保守路线依旧是哈希基签名,安全假设最为成熟,风险最低,适合作为过渡方案。待 FN‐DSA 正式定稿,拥有稳定规范、审计过的代码库、硬件钱包支持之后,Falcon 相比纯哈希签名会带来显著提升;也可以采用混合部署,让两类签名体系互相补充。
