自 Colin Percival 2009 年发布《密码学正确做法》以来，这一传统经 Thomas Ptacek（2015）及 Latacora（2018、2024）延续至今。尽管此次更新看似仓促，但行业格局已发生剧变：后量子密码学过渡的时间线在 2026 年初出现戏剧性转折，业界共识要求该过渡必须在 2029 年前完成。
好消息是，对称加密因 Grover 算法不构成实质威胁而依然安全；坏消息是，非对称加密的建议较 2018 年甚至 2024 年已发生根本性变化。此外，2026 年的另一重大变量是大型语言模型（LLM），"获取你能负担得起的最佳模型的代码审查"已正式与"使用内存安全语言"并列，成为新的密码学最佳实践。
以下建议假设不受特定合规体系限制（大多兼容 FIPS 140）。若需遵循 CNSA 2.0 等更严格规范，请相应替换。
速查表
- 数据加密：云端使用 KMS；本地使用带随机 Nonce 的 XAES-256-GCM 或 XChaCha20-Poly1305；超过几 MB 的数据使用 Cobblestone-128。
- 对称密钥长度：首选 256 位。
- 对称“签名”：HMAC-SHA-256。
- 哈希算法：SHA-2 仍可用；多哈希场景使用 SequenceHash。
- 随机 ID：32 个随机字节（256 位）。
- 密码处理：Argon2id 或 scrypt；强烈建议迁移至 Passkeys（通行密钥）。
- 密钥交换：在标准协议中使用 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。本地加密需采用 AEAD 方案以规避 Nonce 管理风险，推荐 XAES-256-GCM 或 XChaCha20-Poly1305，并配合至少 128 位的随机 Nonce。对于超过几 MB 的大消息，严禁直接传递给 AEAD 或使用未认证流密码，应使用 STREAM 构造。推荐 Cobblestone-128（一种源自 TLS 的 STREAM 变体），其已在 pyca/cryptography 中可用，并将纳入 Go 标准库。
避免：未认证模式（CBC、CTR、原始流密码）、自行构建 AEAD、在未计算消息数量限制时使用随机 96 位 Nonce。
对称密钥长度
不必焦虑，首选 256 位。虽然 Grover 算法威胁有限且不存在 128 位暴力攻击，但 256 位密钥可有效排除多目标攻击。无需为此更改 TLS 库默认密码套件，AES-256 的性能损耗在实践中通常可忽略。
避免：非 128/256 位长度、不均匀密钥（如直接使用密码或 ASCII 十六进制字符串）。
对称“签名”
坚持使用 HMAC-SHA-256。务必通过验证原始字节串来规避规范化器和解析器对齐漏洞，即先检查 HMAC，再处理内部数据。若底层哈希可用，也可选择 KMAC 或键控 BLAKE3。
避免：自行构建 MAC、加密哈希、独立单次 MAC（如 Poly1305 或 GMAC）。
哈希算法
SHA-2 仍然可靠。优选 SHA-512/256 以抵御长度扩展攻击，SHA-256 和 SHA-512 亦可接受。SHA-3 非必要且较慢，但若已因 ML-KEM/ML-DSA 引入 Keccak，可从 SHAKE128 提取 32 字节。多哈希场景（如同时哈希文件名和内容）请使用 SequenceHash（基于 SHA-2）或 TupleHash（基于 SHA-3）。
避免：SHA-1、MD5、自行构建多哈希、截断至少于 256 位。
随机 ID
使用 32 个随机字节（256 位）。UUIDv4 等 API 仅提供约 128 位熵，仅在唯一值需求低于 2⁴⁸ 时适用。应调用操作系统 CSPRNG（如 Linux getrandom、Windows ProcessPrng）。
避免：非密码学 PRNG、用户空间随机数生成器（如 OpenSSL、haveged、CPU 抖动熵）。
密码处理
推荐 Argon2id 或 scrypt。Argon2id 参数建议为 m=64 MiB, t=2, p=1；scrypt 为 N=2^16, r=8, p=1。鉴于 bcrypt 的 72 字节截断限制，已不再推荐。
更重要的是，应评估是否可迁移至防钓鱼的 Passkeys，或以电子邮件魔术链接、OIDC SSO 作为替代。需注意，2026 年的 Passkeys 尚不具备后量子安全性，但仍能有效防御钓鱼和凭证填充。
避免：普通哈希、过度关注密码哈希而忽视 Passkeys 迁移、可钓鱼的电子邮件登录变体。
密钥交换
在安全、标准的协议中使用 X25519+ML-KEM-768。切勿自行构建密钥交换协议，应在 TLS 中选择 X25519MLKEM768，在 SSH 中选择 mlkem768x25519-sha256，或在 HPKE/age 中使用 MLKEM768-X25519。纯 ML-KEM-768 也是可行选项，但混合方案成本极低且更为常见。
避免：名称中不包含 ML-KEM 或 X-Wing 的任何方案。
非对称加密
采用 HPKE（配置为 MLKEM768-X25519/X-Wing、HKDF-SHA256、AES-128-GCM）或支持新 age1pq 前缀密钥的 age。HPKE 已成为混合加密的标准，尽管相关 PQ KEMs 仍处于草案阶段，但线路格式已稳定。大消息需进行分块处理。
避免：任何非 ML-KEM 基础方案（特别是 RSA 和 NaCl box）、OpenPGP、加密电子邮件。
非对称签名
直接使用 ML-DSA-44。若消息需预哈希，使用“外部-μ (Mu)”签名而非 HashML-DSA。ML-DSA-44 属于 NIST 类别 2，提供高于 128 位的安全余量。混合签名复杂性高且收益有限，除非在 SSH 等特定场景（OpenSSH 10.6 采用 ssh-mldsa44-ed25519），否则应避免复合签名。
鉴于非对称签名成本上升，应尽量避免使用，考虑以 HMAC 或随机会话令牌替代 JWT 签名。
避免：所有非 PQ 选项（RSA/ECDSA/Ed25519）、状态签名（LMS/XMSS）、HashML-DSA、复合签名、OpenPGP。
网站或客户端-服务器应用安全
云端环境使用云服务商的 ALB/NLB。本地部署推荐内存安全的 rustls 或 Go crypto/tls；若需 C 语言库，选择维护良好的 BoringSSL、AWS-LC 或 s2n-tls。确保 TLS 堆栈优先支持 X25519MLKEM768（需 TLS 1.3）。证书管理方面，网站应使用流行且更新的 ACME 客户端，内部应用可考虑自建 ML-DSA-44 X.509 证书。
避免：OpenSSL（因其一致性选择存在问题）、GnuTLS、Mbed TLS、wolfSSL、Botan 等存在已知严重漏洞的库，以及 TLS 1.2 及以下版本。
在线备份
使用 restic 配合长随机密码。restic 采用完全对称加密，不受量子计算机威胁。相比之下，Tarsnap 的非对称加密层基于 RSA，在量子计算面前存在潜在风险，尽管其当前架构在一定程度上缓解了低权限密钥泄露问题，但长期来看已不再推荐。