AEGIS：高速认证加密

AEGIS 的设计目标是充分利用 AES-NI 硬件加速，在现代 CPU 上实现显著超过 AES-GCM 的吞吐量。它曾被提交至 CAESAR 竞赛，后来又在 IETF 草案中被提议用于 TLS 和 QUIC。

AEGIS 有两个主要变体：AEGIS-128（128 位密钥、128 位随机数）和 AEGIS-256（256 位密钥、256 位随机数）。两者分别提供 128 位和 256 位的认证标签。AEGIS-128L 是一种优化变体，旨在利用现代处理器上更宽的 AES-NI 流水线并行性。

不同于将 AES 作为特定模式中的构建模块的 AES-GCM，AEGIS 通过多次调用 AES 轮函数来维护并演进内部状态。每个加密步骤都会执行多轮 AES，从而能够利用具有宽执行单元的处理器所提供的指令级并行性。

在支持 AES-NI 的处理器上，AEGIS-128L 的吞吐量可达到 100 Gbps 或更高，而 AES-GCM 在相同硬件上通常为 40～60 Gbps。这种约 2～3 倍的性能优势，使 AEGIS 对高带宽网络加密场景很有吸引力。

AEGIS-128L 使用八个 128 位状态字，并在每个步骤处理两个 256 位消息块，从而最大限度地利用 AES-NI 流水线。当处理器能够同时对多条 AES-NI 指令进行流水线处理时，带有“L”的变体比标准 AEGIS-128 具有更高的吞吐量。

AEGIS 提供 128 位机密性，以及 128 位或 256 位的真实性安全性（取决于标签长度）。安全性分析表明，针对完整构造，目前没有已知攻击能够优于穷举攻击。该设计对 AES 轮数的使用较为保守，因此提供了充足的安全裕度。

AEGIS 已由 Crypto Forum Research Group 在 IETF 草案（draft-irtf-cfrg-aegis-aead）中提出，供其标准化。该草案涵盖 AEGIS-128L、AEGIS-128 和 AEGIS-256，并包含测试向量。将其用于 TLS 和 QUIC 密码套件的方案正在积极讨论中。

AEGIS 没有实际可用的软件回退方案：如果没有 AES-NI，其性能会大幅下降，因为每次调用 AES 轮函数都会变得非常昂贵。只有在能够保证所有部署目标（包括虚拟机和容器环境）都支持 AES-NI 时，才应选择 AEGIS。

ChaCha20-Poly1305 被设计为不具备 AES-NI 的环境中的高速 AEAD，例如 ARMv8 之前的移动 ARM 处理器和嵌入式系统。在配备 AES 加速的现代 ARM64 上，AEGIS 可能更快；但在硬件能力不一致时，ChaCha20-Poly1305 仍然是安全且通用的选择。

使用 AEGIS 的应用必须仔细审查其部署环境。对于没有 AES-NI 的环境，应实现回退到 AES-GCM 或 ChaCha20-Poly1305 的方案。当 AEGIS 作为首选密码套件提供时，TLS 协商层中的密码灵活性会自动处理这一点。

AEGIS 已获得 AEGIS-cipher 参考实现、通过 Provider API 支持它的 OpenSSL 3.2 及更高版本，以及若干实验性 TLS 协议栈的支持。随着 IETF 草案逐步迈向 RFC，以及高带宽应用寻求超越 AES-GCM 所能提供的性能，其采用范围预计会不断扩大。

关于 AEGIS 硬件要求的说法，哪一项是正确的？

AEGIS 通过在基于状态的设计中使用多个 AES 轮函数，在具备 AES-NI 的硬件上实现了比 AES-GCM 高 2～3 倍的吞吐量。AEGIS-128L 最大限度地利用了流水线并行性。它要求具备 AES-NI，因此不适合硬件能力不一致的环境。针对 TLS 和 QUIC 的 IETF 标准化工作正在进行中。