AEGIS: High-Speed Authenticated Encryption

AEGIS was designed specifically to exploit AES-NI hardware acceleration to the maximum, achieving throughput that significantly exceeds AES-GCM on modern CPUs. It was submitted to the CAESAR competition and later standardized in an IETF draft for use in TLS and QUIC.

AEGIS comes in two primary variants: AEGIS-128 (128-bit key, 128-bit nonce) and AEGIS-256 (256-bit key, 256-bit nonce). Both provide 128-bit or 256-bit authentication tags respectively. AEGIS-128L is an optimized variant designed to exploit wider AES-NI pipeline parallelism on modern processors.

Unlike AES-GCM which uses AES as a building block in a specific mode, AEGIS uses multiple AES round function calls to maintain and evolve an internal state. Each encryption step applies several AES rounds, allowing the design to exploit instruction-level parallelism on processors with wide execution units.

On processors with AES-NI, AEGIS-128L can achieve throughputs of 100 Gbps or more, compared to AES-GCM which typically achieves 40-60 Gbps on the same hardware. This roughly 2-3x performance advantage makes AEGIS attractive for high-bandwidth network encryption scenarios.

AEGIS-128L uses eight 128-bit state words and processes two 256-bit message blocks per step, maximizing the use of AES-NI pipelining. The "L" variant achieves higher throughput than standard AEGIS-128 on processors that can pipeline multiple AES-NI instructions simultaneously.

AEGIS provides 128-bit confidentiality and 128-bit or 256-bit authenticity security (depending on tag length). Its security analysis shows no known attacks better than brute force against the full construction. The design is conservative in its use of AES rounds, providing substantial security margin.

AEGIS has been proposed in an IETF draft (draft-irtf-cfrg-aegis-aead) for standardization by the Crypto Forum Research Group. The draft covers AEGIS-128L, AEGIS-128, and AEGIS-256, and includes test vectors. Adoption in TLS and QUIC cipher suites is being actively discussed.

AEGIS has no meaningful software fallback: without AES-NI, its performance degrades dramatically because each AES round function call becomes expensive. AEGIS should only be selected when AES-NI availability is guaranteed across all deployment targets, including virtual machines and container environments.

ChaCha20-Poly1305 was designed as the high-speed AEAD for environments without AES-NI, such as mobile ARM processors before ARMv8 and embedded systems. On modern ARM64 with AES acceleration, AEGIS may be faster, but ChaCha20-Poly1305 remains the safe universal choice when hardware capabilities vary.

Applications using AEGIS must carefully audit their deployment environment. A software fallback to AES-GCM or ChaCha20-Poly1305 should be implemented for environments without AES-NI. Cryptographic agility in the TLS negotiation layer handles this automatically when AEGIS is offered as a preferred cipher suite.

AEGIS is supported in the AEGIS-cipher reference implementation, OpenSSL 3.2+ via the Provider API, and several experimental TLS stacks. Its adoption is expected to grow as the IETF draft progresses toward RFC status and as high-bandwidth applications seek performance beyond what AES-GCM can offer.

Which statement about AEGIS hardware requirements is correct?

AEGIS provides 2-3x higher throughput than AES-GCM on AES-NI hardware by using multiple AES round functions in a state-based design. AEGIS-128L maximizes pipeline parallelism. It requires AES-NI and is not suitable when hardware capabilities vary. IETF standardization is in progress for TLS and QUIC use.