为生产系统选择 AEAD

对于大多数生产系统，AES-GCM 是正确的默认 AEAD。它通过 AES-NI 在几乎所有现代 x86 和 ARM64 处理器上获得硬件加速，得到各种 TLS 协议栈和密码学库的广泛支持，并且经历了大量密码分析和实际部署的检验。

AES-GCM 使用 96 位随机数。使用随机生成的随机数时，在同一个密钥下加密约 2^32 条消息后会达到生日界限，此时随机数发生碰撞的概率将变得不可忽略。对于高流量系统，必须通过计数器管理随机数，或在加密 2^32 条消息后轮换密钥。

如果没有 AES-NI，或者随机数生成可能不可靠，应选择 ChaCha20-Poly1305。它的软件运行速度快，设计上采用恒定时间实现（能够抵抗计时侧信道），并且在不支持 AES 硬件的环境中，它是 TLS 1.3 要求支持的密码套件。

当随机数可能被复用，或必须以确定性方式生成随机数（例如在无状态服务或密钥封装中）时，应选择 AES-GCM-SIV（RFC 8452）。与标准 AES-GCM 相比，它只需付出适度的性能代价，就能抵抗随机数误用。

当要求最高加密吞吐量，并且能够保证所有部署目标都具备 AES-NI 时，应选择 AEGIS-128L。高带宽网络设备、VPN 集中器和存储加密系统都是理想场景，在这些场景中，AEGIS 相比 AES-GCM 能够带来显著的性能提升。

AES-128 提供 128 位安全性，这被认为足以应对当前及可预见的经典计算威胁。AES-256 可针对未来的技术进步提供更大的安全裕度，并且某些合规框架要求使用它（例如 NSA Suite B 中的 TOP SECRET 密级）。对于大多数应用，AES-128 已经足够，而且速度略快。

AES-GCM 使用 96 位随机数，AES-GCM-SIV 同样使用 96 位随机数。XSalsa20（用于 libsodium 的 secretbox）使用 192 位随机数，因此在同一个密钥下，可以安全地为多得多的消息随机生成随机数。更长的随机数能够降低高流量系统中意外复用的风险。

应使用成熟的 AEAD 库，而不是直接实现底层原语。libsodium 提供简单的 AEAD API（crypto_aead_aes256gcm_encrypt、crypto_aead_chacha20poly1305_ietf_encrypt）。Google Tink 为 AEAD 原语封装了密钥轮换和版本管理。各语言原生的 TLS 库会自动处理用于传输安全的 AEAD。

使用独立 HMAC-SHA256 的 AES-CBC（采用 EtM 顺序）虽然可以接受，但属于旧式方案。迁移到 AES-GCM 后，可以用一个原语替代两个原语，从而简化实现并消除组合不当的风险。在计划的密钥轮换期间，应将使用 CBC-HMAC 加密的静态数据重新用 AES-GCM 加密。

应使用 NIST 提供的官方测试向量（针对 AES-GCM）和 RFC 8439 提供的官方测试向量（针对 ChaCha20-Poly1305）来测试 AEAD 实现。始终应测试认证标签验证失败时，解密是否返回错误而不是部分明文。错误处理不当是常见的实现缺陷。

当具备 AES-NI 且随机数唯一时，选择 AES-GCM。当没有 AES-NI 或随机数不够可靠时，选择 ChaCha20-Poly1305。当担心随机数复用时，选择 AES-GCM-SIV。当优先考虑在保证具备 AES-NI 的前提下实现最高吞吐量时，选择 AEGIS。对于新系统，绝不要选择非 AEAD 模式。

AES-GCM 是默认选择。ChaCha20-Poly1305 适用于没有 AES-NI 的环境。AES-GCM-SIV 适用于随机数不安全的环境。在能够保证具备 AES-NI 时，AEGIS 可实现最高吞吐量。应使用 libsodium 或 Tink 等库，而不是手动组合原语。始终使用官方测试向量进行测试，并确认能够正确处理认证失败。