后量子时代加密学实践：Filippo Valsorda 2026年开发最佳选择清单

12 Oct 2026

为开发者发布《密码学正确答案》已成传统。Colin Percival 于 2009 年开了先河，Thomas Ptacek 在 2015 年跟进，接着 Latacora 在 2018 年和 2024 年将其延续了下去。

更新可能让人觉得来得太早，但变化实在太大。后量子迁移的时间表在 2026 年初发生了重大转变，目前已形成共识，需要在 2029 年前完成。2029 年！我们只剩三年！

好消息是，尽管你可能有所耳闻，对称密码学将安然无恙，因为 Grover 算法无关紧要。坏消息是，与 2018 年相比，所有非对称答案都发生了变化，其中大多数甚至与 2024 年相比也发生了变化。

以下答案假设你不受任何特定合规体系的约束，尽管它们在大多数情况下与 FIPS 140 兼容。¹ 如果你需要遵循像 CNSA 2.0 这样更严格的标准，你自然会知道。只需酌情替换即可。

最后，记住 2026 年的另一大变化：LLM 现在非常擅长查找漏洞。「用你负担得起的最好模型做一次审查」现已成为一条板上钉钉的「密码学正确答案」，与经久不衰的经典答案「使用内存安全语言」并列。

如果你赶时间，请看速查表：

数据加密：如果使用云服务，用 KMS。否则，用 XAES-256-GCM 或带随机 nonce 的 XChaCha20Poly1305。如果加密的数据超过几 MB，使用 Cobblestone-128。
对称密钥长度：别纠结。需要指定时，用 256 位密钥。
对称「签名」：HMAC-SHA-256。
哈希算法：SHA-2 仍可使用，但如果需要真正的多重哈希，请用 SequenceHash。
随机 ID：32 个随机字节，即 256 位随机数。
密码处理：Argon2id 或 scrypt。不过你考虑过改用 passkey 吗？
密钥交换：在安全的标准协议中使用 X25519+ML-KEM-768。
非对称加密：HPKE 配合（MLKEM768-X25519 即 X-Wing、HKDF-SHA256、AES-128-GCM），或者使用 age 配合 PQ 密钥。
非对称签名：ML-DSA-44。
网站或客户端-服务器应用安全：如果使用云服务，用它的 ALB/NLB。否则，用 rustls、Go 的 crypto/tls、BoringSSL、AWS-LC 或 s2n-tls，配合一款流行且及时更新的 ACME 客户端。
在线备份：restic 配合一个长的随机密码。

下面我们来逐条展开。

数据加密

如果使用云服务，用 KMS。否则，用 XAES-256-GCM 或带随机 nonce 的 XChaCha20Poly1305。如果加密的数据超过几 MB，使用 Cobblestone-128。

Percival，2009：AES-CTR 配合 HMAC。
Ptacek，2015：NaCl/libsodium 的默认设置，或 ChaCha20Poly1305，或 AES-GCM。
Latacora，2018：KMS，或 XSalsa20+Poly1305。
Latacora，2024：KMS，或 NaCl 的 secretbox，或 XChaCha20Poly1305。

Latacora 关于为何以及何时使用云服务 KMS 的论述依然站得住脚，建议先从那里读起。

本地加密时，你想要一个 AEAD，让你无需费心追踪 nonce 或加密消息数量，因此需要至少 128 位的随机 nonce。²

NaCl/libsodium 的 secretbox 只是对一个不太常见的 AE 构造（XSalsa20+Poly1305）的薄薄一层封装，因此我更推荐 XAES-256-GCM 或 XChaCha20Poly1305。前者是把一个标准 KDF 与 AES-GCM 高效地组合起来，打包成扩展随机数的 AEAD，所以即使你的库没有以这个名字提供它，你也可以用 KDF 和 AES-GCM 的 API 自行组装。³

使用随机数时的常规 AES-GCM 和 ChaCha20Poly1305 只有在你确切知道不会用同一个密钥加密超过十亿条消息时才凑合能用。如果你在所有需要的地方都能拿到 AES-GCM-SIV，它也是不错的 AEAD 选择，但这种情况并不常见。一些更新一些的方案还具有密钥承诺（key commitment）等良好特性，但目前尚不普及。

既然你已经有了 AEAD，可以考虑把上下文放到附加数据（additional data）里，比如你为之加密的用户 ID，或者协议的版本号。任何非机密、并且在解密时你一定还知道的内容都可以。

如何处理大消息是非常重要的问题，而 KMS 不会帮你解决。不要把单个大消息直接传给 AEAD，否则你可能不得不在解密时尚未完成认证的情况下处理或存储明文。绝对不要使用未经认证的流密码。相反，你应该使用 STREAM（它不是流密码，而是一种在流上使用 AEAD 的方式……我知道，名字确实很糟）。可选的方案很多——事实上多到过分——可悲的是没有一个是公认答案。Tink 有一个，libsodium 有一个，AWS Encryption SDK 有一个，FLOE 是一个，age 也有一个，等等。我推荐 Cobblestone-128，它是源自 TLS 的一种 STREAM 变体，已经在 pyca/cryptography 中可用，并即将进入 Go 标准库（在此之前可以在 filippo.io/cobblestone 获取）。⁴

避免：未经认证的模式（CBC、CTR、原始流密码）、随机的 96 位随机数（除非你花了大量时间仔细考虑加密消息的数量）、自行拼凑 AEAD 构造。

对称密钥长度

别为这个焦虑。如果需要选，就选 256 位密钥。

Percival, 2009：256 位 AES 密钥。
Ptacek, 2015：256 位密钥。
Latacora, 2018：256 位密钥。
Latacora, 2024：256 位密钥。

记住 Grover 算法其实并不重要，128 位的暴力破解攻击也不存在。不过 256 位密钥可以排除多目标攻击，这倒是不错。

不过，不要因为这一点去做其他决定。例如，推荐的 Cobblestone 套件使用 128 位密钥，这没问题，因为它对多目标攻击做了细致的分析。同样地，也不要去改动你 TLS 库的默认密码套件优先级以强制使用 256 位密钥；没有必要。

AES-256 比 AES-128 慢，因为不幸的是 Rijndael 把轮数与密钥长度绑定在了一起，不过这在实践中可能无关紧要。

避免：使用 128 位或 256 位以外的密钥、对密钥长度过分纠结、使用不均匀的密钥（例如直接把口令或 ASCII 十六进制字符串当作密钥）。

对称“签名”

HMAC-SHA-256。

Percival, 2009：HMAC。
Ptacek, 2015：HMAC。
Latacora, 2018：HMAC。
Latacora, 2024：HMAC。

为 HMAC 欢呼。

请注意规避规范化与解析器对齐（parser alignment）缺陷：始终对一串逐字逐节的原始字节做认证，而不是去重新计算某个东西。

推荐做法：

{
    "inner": "{\"foo\":123}",
    "hmac": "MbPsZq7QGCllJgDnSSy/cyM10HjqiVu35UO7yyY5d3w="
}

先校验 HMAC，然后再处理、存储或转发 {"foo":123}。

避免做法：

{
    "foo": 123,
    "hmac": "MbPsZq7QGCllJgDnSSy/cyM10HjqiVu35UO7yyY5d3w="
}

如果你本来就有理由使用 KMAC 或带密钥的 BLAKE3 的底层哈希函数，可以直接用它们。HMAC-SHA-512 也没问题。

记得用专门的常量时间（constant-time）函数来比对标签。

避免：自己造一个 YoloMAC、加密哈希、以及像 Poly1305 或 GMAC 这样的独立一次性 MAC。

哈希算法

SHA-2 仍然可以，但如果需要，请使用真正的多重哈希（multihash）。

Percival, 2009：SHA-256（SHA-2），并为 SHA-3 做准备。
Ptacek, 2015：SHA-2。
Latacora, 2018：SHA-2。
Latacora, 2024：SHA-2。

如果你能用得上的话，最佳选择仍然是 SHA-512/256，它不受长度扩展攻击的影响。否则，SHA-256 与 SHA-512 都可以。⁵

SHA-3 并不必要（因为 SHA-2 已经够用）且速度较慢，⁶ 但并不是错误的。如果你已经为 ML-KEM 和 ML-DSA 准备了 Keccak（SHA-3），并且想把它用于哈希，可以从 SHAKE128 中取 32 字节。

如今 BLAKE2 是个奇怪的选择。BLAKE3 速度很快，但足够复杂且不常见，你需要有充分的理由去用它，并且有充分理由去信任你的实现。

多重哈希（multihashing）是指你需要同时对多个东西做哈希。例如一行中的多个列，或文件名加上文件内容。它比听起来更微妙，因此请将 SequenceHash 与 SHA-2 一起使用，或将 TupleHash（SP 800-185）与 SHA-3 一起使用。

避免：SHA-1、MD5、所有其他哈希函数、自己实现多重哈希，以及除非密码学家告诉你不用担心碰撞，否则不要截断到 256 位以下。

随机 ID

32 个随机字节，即 256 位随机数。

Percival, 2009：256 位随机数。
Ptacek, 2015：256 位随机数。
Latacora, 2018：256 位随机数。
Latacora, 2024：256 位随机数。

注意，UUIDv4 以及诸如 rand.Text 之类的 API 只会给你约 128 位的值。这通常够用，除非你需要超过 280 万亿（2⁴⁸）个唯一值。256 位有点过度，但也不必不用。

请使用操作系统的 CSPRNG：Linux 上的 getrandom，Windows 上的 ProcessPrng，macOS 与 BSD 上的 arc4random_buf，Web 上的 getRandomValues。好的库会为你封装这些调用。

避免：非加密学 PRNG、用户态随机数生成器（如 OpenSSL 的）、haveged、CPU jitter entropy。⁷

密码处理

Argon2id 或 scrypt。不过你考虑过改用 passkeys（通行密钥）吗？

Percival, 2009：scrypt 或 PBKDF2。
Ptacek, 2015：优先 scrypt，其次 bcrypt，必要时 PBKDF2。
Latacora, 2018：优先 scrypt，其次 Argon2，再 bcrypt，必要时 PBKDF2。
Latacora, 2024：优先 Argon2id，其次 scrypt，再 bcrypt，必要时 PBKDF2。

我的前辈们说过的一切至今仍然完全适用：「你可以随便往墙上扔飞镖来挑一个。」我不再用 bcrypt，是因为它 72 字节的截断会咬人。一个小提示：你可以向审计人员争辩说 scrypt 符合 FIPS 140，因为它的实际 KDF 步骤就是 PBKDF2，而这正是他们想要的。听说这招管用。

对于参数，请忽略 RFC 9106（它显然想毁掉你的生产系统），对 Argon2id（libsodium 的 INTERACTIVE 预设）使用 m=64 MiB, t=2, p=1，对 scrypt 使用 N=2^16, r=8, p=1。它们使用相同的内存，但 scrypt 会多消耗约 1.5 倍的 CPU 时间，且 GPU 耗时只有 ¼，这就是为什么应该优先选择 Argon2id。如果你要做非交互式密钥派生，可以放心地把 m 调大，然后再把 t（或者 scrypt 的 N⁸）调到可忍受的极限。

更重要的是，你真的需要密码吗？如果你只是用它们来登录，能不能换成抗钓鱼的 passkey？或者搭配邮件魔法链接作为备选？又或者直接支持 SSO（只要是 OIDC 而不是 SAML 就行）？

（注意在 2026 年，passkey 仍然不是后量子（PQ）的。这基本没关系。它们仍然是抗钓鱼、抗撞库的。量子攻击者最多只能在拿到某个站点的数据库或截获一次登录时，登录到该特定站点。）

避免：常规哈希、把时间花在思考密码哈希上而不是聚焦 passkey、基于邮件登录的可钓鱼变体。⁹

密钥交换

在安全、标准的协议中使用 X25519+ML-KEM-768。

Percival, 2009：2048 位 Group #14，生成元为 2。
Ptacek, 2015：可能仍是 DH-2048，或 NaCl。
Latacora, 2018：大概什么都不用。或者 Curve25519。
Latacora, 2024：X25519+ML-KEM-768。

2018 年版的 Latacora 回答中提出的疑问是对的：「作为开发者你为什么要在想这些，它到底意味着什么？！」不要自己造密钥交换协议。直接选用 TLS 中的 X25519MLKEM768、SSH 中的 mlkem768x25519-sha256，以及/或者 HPKE 和 age 中的 MLKEM768-X25519。如果你真的需要获取某些密钥，并且知道自己在做什么，TLS 和 HPKE 都提供了「exporter」来派生这些密钥。

由于「先收割后解密」攻击，非 PQ 方案是一项紧迫且持续的隐患；而 PQ 替代方案要么不实用（HQC-KEM、FrodoKEM），要么既不实用又有问题（Classic McEliece）。

对于密钥交换，使用 ECC 混合方案的成本足够低，值得一试，事实上 ML-KEM 通常与 ECDH 一起部署。但是，如果选用或实现混合方案会让你哪怕多花一个月停留在经典非 PQ 密钥交换上，那就直接采用纯 ML-KEM-768。

P-256+ML-KEM-768 也可以，只是没那么常见。NIST P 曲线多年来名声不佳，但我认为 90% 的原因是它们出现在我们还不太懂得如何做好密码工程的时代（以及……怎么说呢，非NPOV 的鼓吹）。针对 NIST P 曲线上 ECDH 的攻击，几乎没有多少会真正影响临时密钥交换。

避免：任何名字里不带 ML-KEM 或 X-Wing（一种特定的 X25519+ML-KEM-768 组合方案）的方案。

非对称加密

HPKE，参数为 (MLKEM768-X25519 即 X-Wing，HKDF-SHA256，AES-128-GCM)，或者带 PQ 密钥的 age。

Percival, 2009：RSAES-OAEP，使用 SHA-256、MGF1+SHA-256，指数 65537。
Ptacek, 2015：NaCl。
Latacora, 2018：NaCl/libsodium（box / crypto_box）。
Latacora, 2024：棘手，等待既定的 PQ 方案。

这是近年来改进最大的回答之一，因为我们终于有了一个做混合加密的标准：HPKE。（此处「混合」指非对称 + 对称，不是经典 + 后量子，名字重载真棒。）

MLKEM768-P256 作为 KEM 选择也可以，只是可用性较差。如果你手头只有纯 ML-KEM-768，那也可以。所有 KDF 和 AEAD 选择都没问题。

如果你的消息很大，采用 Cobblestone 相同的分块方式，用多个连续的 HPKE Seal/Open 调用来替代 AEAD。

注意，PQ HPKE KEM 仍然是草案，这令人恼火。¹⁰ 更糟糕的是，它们不必要地分散在四份草案中，以至于我不得不写 filippo.io/hpke-pq。但我让作者郑重承诺不会修改线上格式，然后我们都在自己的密码学库里加入了它们，所以你可以也应当使用它们。

如果你需要更高级的方案，支持多个收件人或 CLI，请使用 age¹¹ 及其新的 age1pq 前缀密钥（基于 MLKEM768-X25519）。PQ 支持也正在 YubiKey 和 Secure Enclave 等插件中逐步推出。

避免：再说一遍，任何不基于 ML-KEM 的方案（尤其是 RSA 和 NaCl 的 box¹²）、OpenPGP、加密电子邮件。

非对称签名

ML-DSA-44。

Percival, 2009：RSASSA-PSS with SHA-256, MGF1+SHA-256, and exponent 65537。
Ptacek, 2015：NaCl、Ed25519 或 RFC 6979。
Latacora, 2018：NaCl 或 Ed25519。
Latacora, 2024：短期用 Ed25519，否则用 Ed25519+ML-DSA-65。

在 2026 年 1 月，我本来会告诉你拭目以待，然后一切开始加速。你的认证也需要迁移到 PQ。

直接使用 ML-DSA-44。如果你的消息需要预哈希，使用 "external-μ (Mu)" 签名，而不是 HashML-DSA。密钥一律以 32 字节种子形式存储。

另外两个 PQ 替代方案是 FN-DSA（仍卡在美国商务部）和 SLH-DSA（基于哈希函数）。后者在某些专业场景下有意义，但速度慢、体积大，且在实现中并不普及。

为什么不使用混合或"组合"方案？混合认证更复杂，也没混合密钥交换那么有用。关于这一点我需要写一篇长文，但简而言之：要么你已经有密钥轮换策略，可以在不太可能发生的密码分析突破情况下轮换回 RSA/ECDSA/Ed25519；要么你的时间跨度很长，反正应当假设量子计算机会破解经典那一半。

而且，ML-DSA 是比其前身好得多的签名算法。它具备对冲随机性（比随机和确定性 nonce 都更好）、内置上下文、SUF-CMA 等额外属性，并且相对易于实现和测试。

既然我推荐 ML-KEM-768，为什么要用 -44 参数集？与 ML-KEM-512（NIST 第 1 类）不同，ML-DSA-44 处于 NIST 第 2 类，已经在 128 位安全级别之上留有一定余量。

"不使用组合"规则的唯一例外是 SSH 密钥。OpenSSH 10.6 选择了 ssh-mldsa44-ed25519。我认为他们犯了一个错误，但如果你在那里另辟蹊径，那才是错误。

请注意，非对称签名被过度使用了，尤其是现在它们的成本已经不低，你应当尽量避免使用。请考虑是否能改用简单的 HMAC。也许你可以用随机会话令牌来替代已签名的 JWT。如果确实需要公开对某事作出承诺，请考虑是否应该使用透明度日志，以获得更切实可用的不可否认性概念（并在将签名分摊到多个证明上时可能得到更小的体积）。

避免使用：所有非 PQ 选项，如 RSA/ECDSA/Ed25519，有状态签名（LMS/XMSS）、HashML-DSA、ML-DSA “半扩展密钥”、组合签名、OpenPGP。

网站或客户端-服务器应用安全

如果你在云端，请使用其自带的 ALB/NLB。否则，请使用 rustls、Go 的 crypto/tls、BoringSSL、AWS-LC 或 s2n-tls，并搭配一款流行且持续更新的 ACME 客户端。

Percival, 2009：网站使用 OpenSSL，应用使用定制 RSA 协议。
Ptacek, 2015：使用 OpenSSL，或在条件允许时使用 BoringSSL。也可以直接使用 AWS ELB。
Latacora, 2018：使用 AWS ALB/ELB 或 OpenSSL，配合 Let's Encrypt。
Latacora, 2024：使用 AWS ALB/ELB 或 OpenSSL，配合 Let's Encrypt。

不再推荐 OpenSSL 可能是我最不实用的建议，但 OpenSSL 多年来一直做出令人费解且问题频出的决策。pyca/cryptography 的作者们在一篇关于 OpenSSL 问题的长文中如此总结道：

我们对 OpenSSL 的体验多年来一直呈负面趋势。

他们甚至在 2025 年 OpenSSL 大会上做了演讲（!?），显然毫无结果。批评 OpenSSL 的不止他们：服务器端有HAProxy，客户端有curl。

我推荐 rustls 或 Go 的 crypto/tls，¹³它们是内存安全的。如果你需要坚持使用 C 语言，BoringSSL 和 AWS-LC 都是维护得非常专业的 OpenSSL 分支，后者与 BoringSSL 不同，发布的是有版本号的发行版。如果不需要 libssl 兼容性，s2n-tls 和 rustls-ffi 是不错的选择。

无论使用哪种，都要确保它优先采用 X25519MLKEM768 密钥交换，这需要 TLS 1.3。你的云负载均衡器可能要求你选择 PQ 安全策略。在 RHEL 9 及其衍生版上，你需要主动启用。

之前的清单将网站和客户端-服务器应用程序分开。我把它们合并了，因为如今两者可以使用相同的 TLS 协议栈。不同的是 PKI。对于你可以控制两端的应用程序，可以考虑制作自己的 ML-DSA-44 X.509 证书，自签名或由私有根证书签发。对于网站，配置一个流行的、支持良好的 ACME 客户端，并保持更新。默克尔树证书将于 2027 年推出，你希望处于有利位置以便被纳入这次过渡。

避免：自行实现传输协议，使用那些曾经在其核心任务上失败的 TLS 库（GnuTLS¹⁴、Mbed TLS¹⁵ ¹⁶ ¹⁷、wolfSSL¹⁸ ¹⁹ ²⁰ ²¹ ²² ²³ ²⁴ ²⁵、Botan²⁶ ²⁷）、非主流的 TLS 库、3.5 版本之前的 OpenSSL（首个支持 X25519MLKEM768 的版本）、如果可以的话任何 OpenSSL、TLS 1.0–1.1、如果可以的话 TLS 1.2，以及自行实现 ACME 客户端。

在线备份

restic 配合一个长随机密码。

Percival, 2009：Tarsnap。
Ptacek, 2015：Tarsnap。
Latacora, 2018：Tarsnap。
Latacora, 2024：Tarsnap。

我很久以前检查过 restic 的加密，当时它有点奇怪但效果不错。它是完全对称的，所以不怕量子计算机。此后似乎没有任何变化。如果你需要云存储，rsync.net 为 restic 用户提供了一个 “secret” 套餐，并且他们支持仅追加模式。

我们都喜欢 Tarsnap，我觉得我此刻正在背叛我的前辈们……但它的非对称加密层全都是 RSA。从技术上讲，我认为真正会被破坏的只是能力较低的密钥：只写密钥可以解密归档，而只读密钥可以伪造归档。服务器身份认证使用 HMAC，且 RSA 公钥永远不会发送到服务器。从这个意义上说，Tarsnap 与 restic 一样安全，这对于一个 2008 年的设计来说是一项了不起的成就。然而，面对即将到来的量子计算机，这感觉像是一个重大隐患。

这张图

你可以直接走到它面前，真是有点不可思议。

The Colosseum, at night, pictured from the ground looking up.

在 Bluesky 上关注我 @filippo.abyssdomain.expert，或在 Mastodon 上关注我 @filippo@abyssdomain.expert。

FIPS 140 在模块验证方面仍有一些非常糟糕的地方（运行时自检、完整性检查以及日益恶化的 RNG 乱象），但如今其实际的加密算法“其实是好的”。 ↩
你可能看到过 GCM 可以使用 128 位 nonce 的说法，但当你这样做时，它就不再有单独的 CTR 计数器了，并且使用不同 GCM nonce 的消息最终可能共享 CTR 密钥流，这使得分析变得更加复杂。 ↩
完全披露：XAES-256-GCM 是我的设计，但现在已有多个第三方实现，包括作为 Google Tink 库的一部分，还有Amazon Web Services 的安全性分析，并且它被Microsoft 在官方 SDK 中使用。 ↩
再次声明，完全披露，这是我的设计，但它已被外部广泛采用，所以我放心推荐它。 ↩
在 64 位机器上，SHA-512/256 和 SHA-512 由于块大小更大，理论上应该比 SHA-256 更快，但目前 SHA-256 的硬件支持更广泛，所以实际中 SHA-256 更快。两者都快，所以你可能并不在意。 ↩
部分原因是 NIST 在设计 SHA3-256 时做出的一些选择，使其严格达到与 SHA-256 同等的安全性，即便在 SHA-256 过度设计的地方也是如此。SHA-256 和 SHA3-256 具有 128 比特的抗碰撞性和 256 比特的抗第二原像性。其实只需 128 比特的这两项安全性就足够了，这正是从 SHAKE128 的 256 比特输出中所能获得的。可惜它没有 SHA 名称。TurboSHAKE128（RFC 9861）会更好，但它既不属于 FIPS 140，也没有被广泛使用。 ↩
身处 FIPS 140 这片地狱圈之外的人似乎没有注意到，新的 NIST 规则要求 FIPS 140 模块现在必须具备一个“内部”熵源。如果你的 FIPS 140 “模块”是一段软件……你该怎么办？所有人的答案都是“CPU 抖动”：运行一个访问未缓存内存的紧凑循环，并获取高精度时间戳，希望 CPU 与主存之间的频率失配会让测量结果变得不可预测。在我看来，这是自模块完整性哈希以来 FIPS 140 中最糟糕的部分，而且会让人深受其害。唯一合理的做法是走一遍流程，然后在最后关头把结果与内核熵混合，就像 Go 那样。然而，这比单纯做 CPU 抖动更难向验证实验室解释，所以我担心在生产环境中会大量出现纯 CPU 抖动的方案。 ↩
Argon2id 的参数大致符合直觉，而 scrypt 的参数则不然。 ↩
带有不透明随机令牌、用于登录发起浏览器的那种链接极难被钓鱼。而用于登录发起登录流程的那个浏览器的链接则非常容易被钓鱼。短数字验证码被钓鱼的难度居中。（你可以通过 Broadcast Channel API 把令牌从新标签页传回原标签页，从而兼得两全其美。） ↩
我在另一场合说过，如果这是一个严肃的工程社区，就应该对我们浪费了向后量子密码学过渡的五年时间中的两年、却只产出了与 2024 年相比毫无变化的规范进行事后复盘。不过那是以后的事了。 ↩
再次再次，完整披露：这是我设计的，不过选它基本没有争议。 ↩
我真不明白我的前任为什么会推荐 NaCl 的 box。它是一个极其锋利且底层的 API，却伪装成高级别且安全的 API。 ↩
最后一次，完整披露：我是一名 crypto/tls 维护者。 ↩
CVE-2020-13777，GnuTLS 3.6.4–3.6.13：会话票据密钥全为零，破坏了 TLS 1.2 的机密性，并允许在 TLS 1.3 中绕过认证。 ↩
CVE-2023-45199，Mbed TLS 3.2–3.4：通过 TLS 1.3 握手中超大的密钥共享实现预认证远程代码执行。 ↩
CVE-2026-34873，Mbed TLS 3.5.0–4.0.0：TLS 1.3 会话恢复允许客户端冒充。 ↩
CVE-2026-25835，Mbed TLS 2.18.0–3.6.5 以及 4.0.0：RNG 状态在 fork 后被复制，导致父子进程产生相同的随机值。 ↩
CVE-2026-5194，wolfSSL 3.12.0–5.9.0：通过提供 ML-DSA 或 Ed25519 签名算法标识符以及对零长度摘要的平凡 ECDSA 签名，可以伪造 ECDSA 证书的签名。 ↩
CVE-2026-5501，wolfSSL 5.9.0 及之前版本：当任何有效的终端实体证书作为"中间证书"提供时，OpenSSL 兼容层会跳过叶证书的签名检查。 ↩
CVE-2026-11310，wolfSSL 5.8.4–5.9.1：OpenSSL 兼容层允许调用方提供的不可信中间证书充当信任锚。 ↩
CVE-2026-11999，wolfSSL 5.7.4–5.9.1：OpenSSL 兼容层接受任何超过最大路径深度 100 的链，而无需到达信任锚。 ↩
CVE-2026-55960，wolfSSL 5.6.4–5.9.1：始终接受原始公钥代替证书，从而绕过身份验证。 ↩
CVE-2026-93302，wolfSSL 5.3.0–5.9.2：受信任对等证书按名称而非公钥进行匹配。 ↩
CVE-2026-89136，wolfSSL 5.6.0–5.9.2：客户端仍然接受来自服务器未经请求的原始公钥，从而绕过身份验证。 ↩
CVE-2026-89135，wolfSSL 5.8.4–5.9.2：OpenSSL 兼容层中的链验证失败会永久地将攻击者的 CA 添加到用于原生 TLS、OCSP 和 CRL 检查的信任库中。 ↩
CVE-2026-34580，Botan 3.11.0：DN 与受信任根匹配的终端实体证书会被接受，就好像它就是该根证书一样。 ↩
CVE-2026-34582，Botan 3.11.1 之前版本：TLS 1.3 服务器在 Finished 之前处理应用数据，因此客户端可以完全跳过 Certificate、CertificateVerify 和 Finished，从而完全绕过客户端身份验证。 ↩