NIST P-256后门疑云终结：种子竟是1997年时间戳

二十多年来，NIST P-256 等曲线的“魔法种子”一直是密码学圈的一桩悬案。种子来源不明，让“NSA 植入了后门”的猜测始终无法被彻底驳倒。这个月，Anthropic 的 Claude 研究模型把种子追溯到了一个 1997 年的 Unix 时间戳，用 11 行 C 代码就能复现。悬案告破，但事情并没有完全结束。

种子谜团：从 FIPS 186-2 到悬赏

P-192、P-224、P-256、P-384 和 P-521 在 2000 年随 FIPS 186-2 发布。每条曲线的 b 系数，都是对一段 20 字节种子做 SHA-1 得到的。种子由 NSA 提供，从未公开解释来源。据称生成者 Jerry Solinas 曾表示它们是英文句子的哈希，类似“Jerry deserves a raise”，但他已于 2023 年去世，这个说法始终无人复现成功。

2023 年 10 月，Filippo Valsorda 发起悬赏：12288 美元征集种子，若获奖者将奖金捐出则翻三倍。

2026 年 10 月 15 日，Anthropic 团队认领了这笔悬赏。据其研究文章，一名员工让内部 Claude 研究模型推演种子的生成方式，不到半小时就有了结果。英文句子的说法是错的。实际方法如下：

• 种子是 POSIX srand48/lrand48 系列 PRNG 的原始输出，以当前 Unix 时间作为种子，不涉及哈希。
• 破绽在于：四个种子中每个 32 位字的高位都是零。lrand48 只返回其 48 位状态的高 31 位，剩余 17 个隐藏位通过暴力破解恢复；对于保留位数更少的输出（lrand48() >> 23），则用 LLL 格基约减恢复状态。
• 将状态向前回退，就落在 srand48 由时间戳设定的位置。素域曲线的时间戳集中在 1997 年 5 月至 1998 年 4 月之间。
• 程序每次抽取 20 字节作为一个候选种子，若生成的曲线无效就继续。P-256 在第 1842 次迭代命中。

Filippo 用 Go 重新实现，输出完全一致。他给出的时间戳是：P-521 为 1997-08-08，P-256 为 1997-08-16，P-384 为 1997-08-30，P-224 为 1998-04-03。36864 美元奖金捐给了 Let's Encrypt 背后的 ISRG。

亲手复现 P-256 种子

你可以自己验证。P-256 属于截断情形：种子的每个字节是 lrand48() >> 23，每个候选需要调用 20 次。以下代码在 glibc 上可直接运行：

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    srand48(871696354L);             /* 1997-08-16 01:52:34 UTC */
    unsigned char seed[20];
    for (long i = 1; i <= 1842; i++)
        for (int j = 0; j < 20; j++)
            seed[j] = (lrand48() >> 23) & 0xff;
    for (int j = 0; j < 20; j++) printf("%02X", seed[j]);
    printf("\n");
}

$ gcc p256seed.c -o p256seed && ./p256seed
C49D360886E704936A6678E1139D26B7819F7E90

第 1842 个候选，正是官方公布的 P-256 种子，逐字节吻合。Anthropic 的文章说得很直白：“这不是密码学破解、新攻击或 ECDSA 曲线的弱点。”

后门理论为什么站不住了

后门论中真正严肃的版本来自 Bernstein 和 Lange 在 2017 年的分析：如果 NSA 掌握某一类秘密弱曲线，来源不明的种子就给了他们搜索的空间，按其模型约有 70 比特的自由度，瞄准假设存在的 2^61 条弱曲线。

现在我们知道了输入空间是“1997–98 年的时间戳”。Filippo 算过：即便允许该窗口内任意时间戳、每条曲线取前 16 个素阶候选，也只有“勉强 30 比特的自由度”。他的原话是：“不足以有意瞄准假设中的小类弱曲线，也不足以嵌入任何形式的 NOBUS 后门。”

而且种子在变成 b 之前要经过 SHA-1。你无法先选定想要的曲线再反推出时间戳，只能掷骰子，最多约十亿次。

NOBUS 是“Nobody But Us”的缩写，指一种只有设计者自己能利用、其他任何组织（包括公开的密码分析者）都无法复现的弱点。在密码学讨论中，它通常指算法中嵌入的秘密结构：设计者掌握某种陷门信息，从而能比其他人更快地攻破实例，而外部研究者即便怀疑存在弱点，也无法在合理时间内找到利用方法。NOBUS 后门的关键难点在于，它必须躲过全球范围的公开分析，同时又要让设计者自己觉得“值得一用”。Filippo Valsorda 指出，若种子来自 1997–98 年的时间戳，输入空间只有约 30 比特自由度，设计者无法有意瞄准某一类弱曲线，也就无法构造出这种“仅我们可用”的弱点。

LLL 格基约减（Lenstra–Lenstra–Lovász）是一种在多项式时间内寻找格中短向量的算法，广泛用于密码分析，尤其是对基于线性同余或截断输出的伪随机数生成器进行状态恢复。当 lrand48 的输出被截断得较多时（例如只保留 lrand48() >> 23 的高位），隐藏位增多，直接暴力枚举不可行；此时可以把“观测到的输出位满足线性同余关系”转化为一个格上的短向量问题，用 LLL 恢复完整的 48 位内部状态。一旦状态已知，就能向前回退到 srand48 设定的时间戳位置。这一技术是本次种子追溯能够覆盖所有曲线变体的关键数学工具。

仍未解释的部分

事情并非百分之百闭合，评论区说得对。

• P-256 的生成过程跳过了第 876 个候选，它本也可以给出尺寸合适的素阶曲线。Filippo 统计出“有效种子的数量大约是已公布的两倍”。他识别出一条额外的拒绝规则（n 的位长不能超过 p），但第二条规则“仍然逃过了我们的眼睛”。
• P-224、P-256、P-384、P-521 的基点仍未解释。P-192 的基点已解释，另有一些 ANSI X9.62 曲线（FreeLIP 的 RNG，种子如 20000 和 20420）。
• B-163 的种子同样未解释，一名 Hacker News 评论者怀疑是某位数字打错了。

在 Hacker News 上，fidotron 的反对意见是这一发现“没有说明他们的选择过程”。这有道理。在 Lobsters 上，我认同的一条回复是：关于 2^30 后门的猜测“个人在合理时间内就能测试，且无需告知任何人”，即便在 1997 年也是如此。在一个任何人都能枚举的空间里藏一个“仅我们可用”的弱点，说不通。而且，隐藏弱点要值得利用，必须存在于十亿次随机尝试中真能找到的曲线上。二十五年的密码分析没有发现这样的类别。

顺带一提，基点对此并不重要：在素阶群中，任何生成元都与其它生成元等价。

那为什么还有人选 Ed25519？

我的看法是：支持 Curve25519 的理由一直主要是工程上的，后门传闻只是让这个理由听起来更吓人。

Ed25519 的设计让“容易的实现”同时也是“安全的实现”。签名是确定性的，损坏的 nonce 不会像索尼 PS3 上恒定 ECDSA nonce 那样泄露私钥。X25519 没有需要防御的无效曲线攻击。密钥只有 32 字节，没有多少参数可以填错。

但 P-256 已经追上来了。确定性 ECDSA 写进了 RFC 6979，P-256 也有完整的加法公式和经过形式化验证的域运算。多年维护 Go 密码库的 Filippo 现在写道，他“个人现在会推荐”NIST ECC 而非 Curve25519/Ed25519/X25519。紧接着他又说：“正好赶上它们要被后量子签名取代。”在 Lobsters 上他给出了理由：P-256 无处不在，包括硬件；他宁愿把精力集中到一条实现良好的曲线上，而不是分散到两条；何况新签名本来就有更好的选择 ML-DSA-44。

我的立场是：2026 年做决定，关键问题是你的硬件支持什么、你的库让什么不容易出错。2013 年的传闻不该参与决策。

RFC 6979 定义了确定性 ECDSA（以及 DSA）的 nonce 生成方法：它用私钥和消息哈希作为输入，通过 HMAC 派生每次签名所需的随机数 k，而不是依赖系统随机源。传统 ECDSA 若 nonce 重复或可预测，私钥会立刻泄露——索尼 PS3 的签名失败正是恒定 nonce 所致。确定性方案消除了对随机数生成器的信任假设，使同一消息每次签名产生相同结果。P-256 生态已普遍支持 RFC 6979，这也是 Filippo Valsorda 认为 P-256 在工程安全性上追平 Ed25519 的重要理由之一。

今天该用什么：SSH、JWT、TLS、WebAuthn

场景	选择	理由
SSH 用户密钥	ed25519，或硬件密钥上的 ecdsa-sk/ed25519-sk	Ed25519 是 OpenSSH 的默认选项，有充分理由。FIDO 密钥则用令牌支持的算法
JWT 签名	需要广泛兼容用 ES256，两端都支持则用 EdDSA	ES256 到处都能用，JWT 库对 EdDSA 的支持仍不均衡
TLS 证书	ECDSA P-256	CA 和客户端都针对它优化。密钥交换另行协商（X25519，越来越多地混合 ML-KEM）
WebAuthn / passkeys	同时接受 -7（ES256）和 -8（EdDSA）	多数认证器生成 ES256，两者都不要拒绝
TPM / HSM / Secure Enclave	P-256	往往是硬件唯一支持的曲线

SSH 方面：

**ML-DSA**（Module-Lattice-Based Digital Signature Algorithm）是美国 NIST 后量子密码标准化项目中选定的数字签名算法，前身为 CRYSTALS-Dilithium，已随 FIPS 204 发布。它基于模格上的困难问题，旨在抵抗量子计算机对 RSA/ECC 的 Shor 算法攻击。**ML-KEM**（前身 CRYSTALS-Kyber，FIPS 203）则是密钥封装机制，用于替换 TLS/SSH 中的 (EC)DH 密钥交换。当前实践趋势是“混合模式”：在现有 X25519 或 P-256 密钥交换之外再叠加 ML-KEM，以兼顾经典安全与后量子安全；签名侧则逐步引入 ML-DSA。文中建议把迁移精力优先投入混合后量子密钥交换，正是指这一路线。
# 软件密钥
ssh-keygen -t ed25519 -C "you@laptop"

# 硬件支持（FIDO2 令牌）；令牌不支持 Ed25519 时用 ecdsa-sk
ssh-keygen -t ed25519-sk -O resident -C "you@yubikey"

生产环境里的 P-256 密钥，留着就行。这个月你的密钥没有任何变化，唯一改变的是把它们视为可疑的主要论据消失了。把迁移精力花在后量子规划上：先做 TLS 和 SSH 的混合密钥交换，再随技术栈逐步引入 ML-DSA 签名。

检查清单：

1. 不要因为这个发现轮换 P-256 密钥。
2. 新的 SSH 密钥用 Ed25519；硬件或兼容性要求时用 P-256。
3. 审计所有手写 ECDSA 的 nonce 生成。如果不是 RFC 6979 或 hedged 方案，先修这个再操心种子。
4. WebAuthn 同时接受 ES256 和 EdDSA。
5. 把时间投入到混合后量子密钥交换。

种子左右了你的选择吗？

包括我在内，不少人在某个时刻选了 Ed25519 而非 P-256，并把 NSA 来源不明的种子当作理由。你呢？现在种子被证明只是一个 1997 年的时间戳，这会改变什么吗，还是你其实一直就是冲着 API 去的？如果你认为被跳过的候选仍给后门留了空间，欢迎在评论区说说你会如何利用那 30 比特。