不偷私钥，也能伪造签名

9 月 20 日，一篇预印本挂上 IACR 的 ePrint 服务器，题目直白：《近乎 SNFS 时间的 1024 位 RSA 签名伪造》1。作者五人——加州大学圣迭戈分校的 Laura Shea、Miro Haller、Adam Suhl、Nadia Heninger，以及法国 Inria 的 Emmanuel Thomé，第一作者是 Shea。两天后论文被批准，版本只有一个 1。9 月 24 日，Ars Technica 的安全编辑 Dan Goodin 把它写成一句话：这是迄今见过最快的一条攻破 RSA 的路 2。

要先把话说准：这不是 1024 位 RSA 被分解。 私钥始终没有被算出来。作者用的办法是另一条路——临时拿到一个「裸的」RSA 签名接口，输入一个数，接口回给你私钥运算的结果；问它大约 2^32 次之后，攻击者就拿到了永久离线伪造任意签名的能力 1。约翰霍普金斯大学的 Matthew Green 在论文贴出的当天就把这句话说在了前面：「说清楚，这不是 RSA 1024 的因式分解，这是对 Joux、Naccache、Thomé 2007 年那条攻击的一个实现。」3

论文把这种设定叫「午餐时间攻击」。 学术上的名字是非适应性选择密文攻击（IND-CCA1）：攻击者在一段时间里能问，之后失去接口，被要求交出伪造 1。作者给这个场景起了个新称呼「delayed-target RSA」，给算法的名字是 √e-NFS——开 e 次方根的 NFS。被利用的接口在密码学上只需要一件事：它对任意输入做私钥运算，而不管那个输入是不是一条合法的、带填充的消息。

账目分两段，这才是要紧的地方。 论文报告的总成本是 1,380 CPU core-years、历时五个自然月、2^32 次查询；其中只依赖模数、与目标消息无关的预计算占约 1,200 core-years，而预计算做完之后，离线伪造任意一条签名只要 180 core-years 1。作为对照，论文引用的一份 2021 年文献估计，用因式分解攻破 1024 位 RSA 需要 50 万到 100 万个 CPU core-years 1。作者还写明：代码与文字全部手写，没有用生成式 AI，也没有用 GPU 1；官方仓库的问答把话说得更短——问「AI 或 GPU 能加速这个实现吗」，答案是「几乎可以肯定能」，问「你们用了吗」，答案是「没有」4。所以这三个数字要当上界读，论文自己也这么写：运行时间几乎必然还能改进 1。

为什么这条路能成立，答案在 2007 年。 那一年 Joux、Naccache、Thomé 发表《当 e 次方根比因式分解更容易》，指出在能查询某种 oracle 的前提下，求模 n 的 e 次方根比分解 n 更省力，复杂度落在 L_n(1/3, (32/9)^(1/3))，与特殊数域筛法（SNFS）同级 5。这次的论文解释了它为什么被放了十九年：那篇工作是在 one-more RSA 假设下评估的，把参数代进那个假设，攻击总时间会变成 L(1/3, 2.488)，比直接分解还差 1。换句话说，只要你还认为 RSA 的安全性由那个假设刻画，这条路就不值得走；而这次的实跑把「不值得」换成了「1,380 个 core-year」。

它不是在纸上跑的，是在真的签名机上跑的。 作者用了两台 Thales Luna 硬件安全模块：一台是别人捐的 Luna K6（PCIe 7000，2021 年 6 月对企业停售），一台是第三方远程开放使用的 Luna S750，后者今天仍以 2.2 万到 3.2 万美元出售 1。为了打开裸 RSA 运算，作者主动关掉了 FIPS 140-2 的合规模式，启用 PKCS#11 里的 CKM_RSA_X_509——也就是那个「不过滤输入、直接做私钥运算」的接口 1。本地那台的平均吞吐约每秒 6,500 次签名，远程那台在每秒 2,500 到 5,700 次之间；作者累计发出 4,067,419,331 次查询，并在报告里写下一条结论：这整套询问是可以走公网完成的 1。计算在 2026 年 8 月 31 日跑完 4。

真正改写的是那几栏安全位数。 论文的外推表给出四档：1024 位从通常认为的 80 位降到 65 位，2048 位从 112 位降到 90 位，3072 位从 128 位降到 105 位，4096 位从 144–152 位降到 119 位 1。作者的原话是：这套攻击把「在用密钥长度」的 RSA 安全估计削掉 15 到 30 位；并且即便 4096 位，在这个攻击模型下也够不到 128 位 1。这里的门槛不是随便定的。NIST SP 800-57 第一部分第 5 版把 1024 位 RSA 归在「安全强度不超过 80 位」一档，并在表下写明：估计上限低于 112 位的组合，已不再被批准用于联邦信息上的密码保护 6。也就是说，1024 位今天本来就在不再被批准的那一档里，这次只是把它在这个模型下的实际强度又往下拉了 15 位。

论文自己划了线，这条线比数字更重要。 论文写：现代绝大多数 RSA 用途是 PKCS#1 v1.5 或 RSA-PSS 填充的签名，而一个套用这类填充的 oracle，对伪造签名的帮助在渐近意义上并不比因式分解多出多少 1。原因在数学上：当 oracle 只肯做「仿射模根」查询——这恰好对应 PKCS#1 v1.5 的填充——最佳复杂度变成 L(1/3, 1.817)，已经接近因式分解的 1.923，几乎不划算 1。所以受影响的不是「用 RSA 的所有人」，而是那些真的把裸运算暴露出去的部署：通过 PKCS#11 提供裸 RSA 操作的 HSM；使用了 HSM 接口不支持的填充模式（比如 ISO 9796-2、ANSI X9.31）的系统；Android KeyMint 里允许无填充 RSA 解密的接口；以及盲签名方案 1。论文对这一点的措辞很克制：在它知道的所有盲签名协议里，用的都是 PKCS#1 v1.5 或 PSS 填充，没有一个协议自己提供裸 oracle 1。

被点名的现实部署是 Privacy Pass。 论文写道：Privacy Pass 里可公开验证的那一支——由苹果的 Private Access Tokens 实现，并由 Fastly、Persona、Cloudflare 用于生产——用的就是盲 RSA 1。盲签名在密码学上就是那个接口：签发端对任意（盲化后的）值做私钥运算，攻击者的查询与正常用户的查询无法区分 1。这条路在规范上是有编号的：RFC 9474 把 RSA 盲签名定义为 RSABSSA，RFC 9576 到 9578 给出 Privacy Pass 的架构与签发协议，其中明确点名了基于盲 RSA 的公开可验证变体 78。苹果的文档写得更具体：iCloud Private Relay 的授权用的就是基于 RSA 盲签名的匿名令牌，而且令牌与密钥按天轮换 9。论文还点了 GNU Taler 的 RSA-FDH 盲签名，并算了一笔账：对 2048 位 RSA，要先铸造 880 亿美元的 1 美分硬币才能获得随意伪造的能力；同时它注明 Taler 现在也支持 clause blind Schnorr 签名，那种方案不受这条攻击影响 1。

但现实里横着一道闸：你得先能问。 攻击的第一步是控制或渗透持有该密钥的签发服务；第二步是要在密钥轮换周期结束之前把查询打完，而论文说这个周期「可能是几小时，也可能是几周」 1。按论文自己的换算，Cloudflare 最早的实现是每解一个验证码发 30 个令牌，2048 位需要 2^43 次查询，也就等于单个攻击者要在轮换窗口内解出约 2^38 个验证码 1。论文把查询量与几家公开数字对比：Cloudflare 自述每天处理超过 7 万亿次 HTTP 请求，与 2^43 同一量级，并且每天发出数十亿个 Privacy Pass 令牌 1；苹果看起来把令牌发放限制在每台设备每分钟一个，那么单机跑完 2^43 次需要 1,700 万年，摊到苹果自称的 23 亿台活跃设备上也要 2.3 天 1；而 Persona 按次计费，按其公布价格每次 1.5 美元，跑完这批查询要花 13 万亿美元 1。这些换算都在说明同一件事：接口在结构上存在，但在工程上被速率与轮换夹住。

所以作者自己的定性是「值得警惕，不是今晚就要行动」。 论文写：这套攻击在学术意义上可行，而不是在脚本小子意义上可行；它很可能不构成对多数现代 RSA 部署的即时操作威胁，但它证明在这些场景里 RSA 提供的安全性明显低于基于因式分解的估计 1。2048 位那条路目前还挡着：预计算要 2^90 的量级，论文用「precludes an immediate threat」来描述 1。作者对外推也留了三条保留——忽略渐近式里的常数与 o(1) 项是很大胆的简化、无法保证 1024 位已经进入渐近区间、也无法保证参数取到了最优 1；结论段还补了一句：这套结果不适用于 ECDSA 或 Ed25519 1。理论上的缺口他们也没有解决，原文写的是「我们不解决这个缺口」——RSA 参数长期按 GNFS 的运行时间来定，而这次的攻击说明这个做法本身值得重新审视 1。

外面的评价分两层，得分开读。 第一层是署名专家的判断。网络安全公司 Allurity 的创新负责人 Karsten Nohl 对 Ars Technica 说：「如果这个结果经得起同行评审，它确实会是一次概念性的突破。RSA 被认为和分解大整数一样难破——至少我们以前是这么想的。这位研究者提出的是，你可以在不破解密钥的前提下实际攻破 RSA。」2 第二层是围绕着表格数字的争论。安全研究者 Dino Dai Zovi 从 HSM 吞吐反推，指出高端的 2048 位签名吞吐是每秒 11,680 次，对应「临时访问」要 764 年——但他推的这一步用了 2^48 次查询，而论文的表格与官方问答写的都是 2^43，这个不一致要一并注明 10。有一层背景需要披露：Green 不只是评论者，论文致谢里写明，他捐赠了这次使用的其中一台 Luna HSM 1。讨论热度也值得记一笔：这条论文在 Hacker News 上只有 3 分、0 条评论，Ars 的报道甚至没有被提交上去；Reddit 的 r/crypto 上有一条 21 分的帖子、两条评论，其中一条是转引作者的自述 11。

作者自己的公开说明比论文更好读，也补了论文没有的数。 第一作者团队的 Miro Haller 在 Bluesky 上写：他们终于完成了 1024 位 RSA 的通用签名伪造，2^32 次 oracle 查询、1,200 core-year 预计算、单次伪造 180 core-year，外加「3 年的人力」（原文如此），并特意注明没有 AI 参与 12。同一条串里他说，这条攻击对仍在广泛使用的 2048 位目前太贵，但那些应用的安全位数低于你的预期，而且这个外推很可能高估了攻击成本 12；对盲签名应用，他的判断是：攻击者要解的验证码数量大到不现实，可这些应用的量级，对单个密钥而言与他们的查询次数相当 12。共同作者 Emmanuel Thomé 在同一页面上的那句更直接：「把你的 HSM 交出来一会儿，我们就能为它的密钥伪造签名。任意的签名。永久有效。」12

标准侧的动作比论文更早，也更硬。 美国国安局 2022 年发布的 CNSA 2.0 给出了时间表：软件与固件签名要立刻开始迁移、2025 年起支持并优先使用、2030 年前完全只使用 CNSA 2.0；浏览器与服务器、云服务 2033 年前完成；整套国家安全系统在 2035 年前完成迁移 13。而 CNSA 2.0 的算法清单里已经没有 RSA。欧盟网络与信息安全局的建议力度相近：其算法目录推荐机制应提供至少 125 位安全强度，RSA 的推荐档是模数不小于 3000 位，1900 到 3000 位这一档的遗留可用期限定在 2025 年 12 月 31 日 14；一份 2026 年 4 月的草案把这一档的措辞从「遗留可用」改成了「未获同意」 15。德国联邦信息安全局的 TR-02102-1 当前版本（2026-01）要求 RSA 模数至少 3000 位，并把这一推荐期限写到 2031 年；这一版新增的一条变更是：单独使用经典非对称算法本身，被列入弃用预告 16。顺带校正一个容易传错的点：NIST 那份讲后量子迁移的 IR 8547，目前仍是最初公开草案，不是定稿 17。

落到要动手的那一栏，问题只有四个。 第一，你的部署里有没有裸签名接口：HSM 是否开启了 PKCS#11 的裸 RSA 运算，是否用了接口不支持的填充模式，是否在跑盲签名——三者之一成立，论文说的那个 oracle 就存在；普通的 PKCS#1 v1.5 与 PSS 不构成。第二，密钥与令牌多久轮换一次：苹果的中继是一天一轮，而论文只把「频繁轮换」称为短期缓解，没有说它能消除风险。第三，迁移时间表写在哪一天：软件与固件签名的 2030 年、整套系统的 2035 年、以及你们行业对应那一档的日期。第四，谁能被问、被问了多少次有没有留下记录：攻击的第一步是拿到签发方的控制权，而「谁在什么时间问了多少次」是这一格里唯一能被写进日志与合同的东西。

别把这条攻击读成一条行动指令。 它没有攻破任何生产系统：论文用的 1024 位密钥是作者自己在 HSM 之外生成、再导入进去的，两台 HSM 一台是捐赠、一台由第三方远程开放 1。它也没有削弱 PKCS#1 v1.5 与 PSS 签名的部署——论文自己说了，那类填充的 oracle 帮不上多少忙。真正被改写的是一句被写进采购单很多年的话：「1024 位 RSA 提供 80 位安全」。在带签名接口的部署里，这句话今天的落点是 65 位，已经在 NIST 不再批准的那一档里；2048 位的落点是 90 位，够用与否取决于第一个问题的答案。这份预印本还没经过同行评审，Nohl 的那句「若经同行评审成立」是应有的限定；但把参数强度当成部署的函数、而不是密钥长度的常数，这件事不依赖评审结果。