2026 版密码学正确实践清单：抗量子迁移与开发者建议

2026年10月12日

为开发者发布“密码学正确答案”如今已成为一项传统。Colin Percival 于 2009 年开创先河，Thomas Ptacek 于 2015 年跟进，随后 Latacora 在 2018 年和 2024 年延续了这一传统。

现在更新可能感觉为时过早，但变化实在太多了。后量子迁移的时间线在 2026 年初发生了剧变，如今已达成共识：必须在 2029 年前完成。2029 年！我们只有三年了！

好消息是，尽管你可能听说过相反的说法，对称密码学不会有问题，因为 Grover 并不重要。坏消息是，与 2018 年相比，所有非对称密码学的答案都变了，大多数甚至与 2024 年相比也变了。

以下答案假设你不受任何特定合规制度的约束，尽管它们大多与 FIPS 140 兼容。¹如果你需要遵循更严格的标准，比如 CNSA 2.0，你自己会知道的。按需替换即可。

最后，请记住 2026 年的另一个重大变化：LLM 现在非常擅长发现漏洞。“用你能负担得起的最好的模型做一次审查”如今已稳居密码学正确答案之列，与长期以来的经典答案“使用内存安全的语言”并列。

如果你赶时间，这里是速查表：

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

现在让我们深入探讨。

加密数据

如果在云端，用 KMS。否则，使用带随机 nonce 的 XAES-256-GCM 或 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 的高效组合，被打包为扩展 nonce 的 AEAD，所以即使你的库没有以这个名字提供它，你也可以用 KDF 和 AES-GCM 的 API 自行组装。³

使用随机 nonce 的常规 AES-GCM 和 ChaCha20Poly1305 只有在你确定不会用同一个密钥加密超过十亿条消息时才可以。如果你恰好在所有需要的地方都有 AES-GCM-SIV，它也是一个不错的 AEAD 选择，但这不太可能。一些更新的选项具有密钥承诺等良好特性，但尚未普遍可用。

既然你有了 AEAD，可以考虑把上下文放进附加数据中，比如你正在为其加密的用户 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 位 nonce（除非你花了大量时间思考你加密多少条消息），自己拼凑 AEAD 构造。

对称密钥长度

别为此焦虑。如果需要选择，就用 256 位密钥。

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

记住 Grover 实际上并不重要，128 位暴力破解攻击也不存在。不过，256 位密钥可以排除多目标攻击，这很不错。

但是，不要基于此做出其他决定。例如，推荐的 Cobblestone 套件使用 128 位密钥，这没问题，因为它对多目标攻击进行了仔细分析。同样，不要为了强制使用 256 位密钥而更改 TLS 库的默认密码套件偏好；没有必要。

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

避免：128 或 256 位以外的任何长度，过度担心长度，非均匀的密钥（例如直接使用密码或 ASCII 十六进制字符串作为密钥）。

对称“签名”

HMAC-SHA-256。

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

为 HMAC 欢呼。

只要小心避开规范化（canonicalization）和解析器对齐的 bug，始终对逐字节原样的字符串进行认证，而不是需要重新计算的东西。

好：

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

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

坏：

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

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

记得用专门的常量时间函数来比较标签。

避免：自己造 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 是指你需要同时哈希多个东西。例如，一行中的多个列，或者文件名连同文件内容。它比听起来更微妙，所以请使用带 SHA-2 的 SequenceHash，或带 SHA-3 的 TupleHash（SP 800-185）。

避免：SHA-1、MD5、所有其他哈希函数、自己造 multihash、截断到少于 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，它显然想谋杀你的生产系统，使用 m=64 MiB, t=2, p=1 用于 Argon2id（libsodium 的 INTERACTIVE 预设）或 N=2^16, r=8, p=1 用于 scrypt。它们使用相同的内存，但 scrypt 的版本将花费约 1.5 倍的 CPU 时间和 ¼ 的 GPU 时间，这就是为什么你应该更喜欢 Argon2id。如果你在进行非交互式密钥派生，可以随意提高 Argon2id 的 m，然后 t（或者对于 scrypt 只是 N⁸）尽可能高。

更重要的是，你真的需要密码吗？如果你只需要它们用于登录，你能改用防钓鱼的 passkeys 吗？也许用电子邮件魔法链接作为后备？或者只支持 SSO（只要它是 OIDC 而不是 SAML）？

（注意在 2026 年，passkeys 仍然不是 PQ。这大多没问题。它们仍然防钓鱼和防凭证填充。量子攻击者所能做的只是在获取特定网站的数据库或拦截登录时登录该网站。）

避免：常规哈希、花时间思考密码哈希而不是专注于 passkeys、基于电子邮件的可钓鱼登录变体。⁹

密钥交换

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 都有“导出器”来派生它们。

非 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)，或 age 使用 PQ 密钥。

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：使用 SHA-256、MGF1+SHA-256 和指数 65537 的 RSASSA-PSS。
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 客户端并保持更新。Merkle Tree Certificates 将于 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 用户提供了一个“秘密”方案，并且他们支持仅追加模式。

我们都喜欢 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 库的一部分，还有亚马逊云科技的安全分析，并且它被微软用于一个官方 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 位就足够了，这正是 256 位 SHAKE128 输出所能提供的。遗憾的是，它没有 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，这是一次完整的客户端身份验证绕过。 ↩