Selecting AEAD for Production Systems

AES-GCM is the correct default AEAD for most production systems. It is hardware-accelerated via AES-NI on virtually all modern x86 and ARM64 processors, widely supported across TLS stacks and cryptographic libraries, and benefits from extensive cryptanalysis and real-world deployment experience.

AES-GCM uses a 96-bit nonce. With randomly generated nonces, the birthday bound is reached after approximately 2^32 messages under the same key, at which point nonce collision probability becomes non-negligible. For high-volume systems, nonce management via a counter or key rotation after 2^32 messages is essential.

ChaCha20-Poly1305 is the correct choice when AES-NI is not available or when nonce generation may be unreliable. It is fast in software, constant-time by design (resistant to timing side-channels), and is the mandatory cipher suite in TLS 1.3 for environments without AES hardware support.

When nonces may be reused or must be generated deterministically (such as in stateless services or key wrapping), AES-GCM-SIV (RFC 8452) is the correct choice. It provides nonce-misuse resistance at a modest performance cost compared to standard AES-GCM.

AEGIS-128L is the correct choice when maximum encryption throughput is required and AES-NI is guaranteed to be present on all deployment targets. High-bandwidth network appliances, VPN concentrators, and storage encryption systems are prime candidates where AEGIS provides meaningful performance gains over AES-GCM.

AES-128 provides 128-bit security, which is considered adequate for all current and foreseeable classical computing threats. AES-256 provides additional margin against future advances and is required for some compliance frameworks (such as TOP SECRET classification under NSA Suite B). For most applications, AES-128 is sufficient and slightly faster.

AES-GCM uses 96-bit nonces, while AES-GCM-SIV also uses 96-bit nonces. XSalsa20 (used in libsodium secretbox) uses 192-bit nonces, making random nonce generation safe for far more messages under the same key. Larger nonces reduce the risk of accidental reuse in high-volume systems.

Use established AEAD libraries rather than implementing primitives directly. libsodium provides a simple AEAD API (crypto_aead_aes256gcm_encrypt, crypto_aead_chacha20poly1305_ietf_encrypt). Google Tink wraps AEAD primitives with key rotation and versioning. Language-native TLS libraries handle AEAD automatically for transport security.

AES-CBC with a separate HMAC-SHA256 (in EtM order) is acceptable but legacy. Migration to AES-GCM simplifies the implementation by replacing two primitives with one and eliminates the risk of incorrect composition. Data at rest encrypted with CBC-HMAC should be re-encrypted with AES-GCM during scheduled key rotation.

AEAD implementations should be tested against official test vectors from NIST (for AES-GCM) and RFC 8439 (for ChaCha20-Poly1305). Always test that authentication tag verification failures cause decryption to return an error rather than partial plaintext. Incorrect error handling is a common implementation flaw.

Choose AES-GCM when AES-NI is present and nonces are unique. Choose ChaCha20-Poly1305 when AES-NI is absent or nonces are less reliable. Choose AES-GCM-SIV when nonce reuse is a concern. Choose AEGIS when maximum throughput with guaranteed AES-NI is the priority. Never choose non-AEAD modes for new systems.

A stateless microservice deployed across multiple replicas must encrypt data and cannot coordinate a shared nonce counter. Which AEAD mode is most appropriate?

AES-GCM is the default. ChaCha20-Poly1305 covers environments without AES-NI. AES-GCM-SIV handles nonce-unsafe environments. AEGIS maximizes throughput when AES-NI is guaranteed. Use libraries like libsodium or Tink rather than composing primitives manually. Always test against official test vectors and verify authentication failures are handled correctly.