Skip to content

AEAD (authenticated encryption)

One call that encrypts and also proves nothing was changed: a key, a nonce that never repeats, and a tag. AES-GCM and ChaCha20-Poly1305 carry most of today's traffic.

Status and standards: see Cipher modes and AEAD in the main table.

What it is

Plain encryption hides data but doesn't stop changes: flip a bit of a CTR or ChaCha20 ciphertext and the same bit flips in the plaintext. Protocols used to glue a cipher to a MAC themselves and often got it wrong; the CBC padding oracles in TLS came from that (see Classic modes). An AEAD, authenticated encryption with associated data, does both jobs in one algorithm. RFC 5116 (2008) fixed the interface protocols code against:

  • encrypt(K, N, P, A) returns the ciphertext with a tag on the end, and decrypt(K, N, A, C) returns the plaintext or FAIL, nothing else.
  • K, the key: random and secret.
  • N, the nonce: not secret, but it must never repeat under one key. RFC 5116 recommends 12 bytes, a fixed part plus a counter.
  • A, the associated data: headers, sequence numbers, a file name. It stays readable but the tag covers it, so changing one byte of it makes decryption fail.
  • The tag, usually 16 bytes. Without the key nobody can make a valid one.
Algorithm Key Nonce Tag Built from If a nonce repeats Where
AES-GCM 128 / 256 96 128 AES-CTR + GHASH XOR of plaintexts leaks; forgeries under the whole key TLS, IPsec, SSH
ChaCha20-Poly1305 256 96 128 ChaCha20 + Poly1305 XOR of plaintexts leaks; forgeries under that nonce TLS, WireGuard, SSH
AES-GCM-SIV 128 / 256 96 128 AES-CTR + POLYVAL, keys per nonce only shows two messages were equal nonces you can't trust
AES-CCM 128 / 256 56–104 32–128 AES-CTR + CBC-MAC XOR of plaintexts leaks Wi-Fi, Bluetooth LE, Zigbee
AES-OCB 128 / 256 up to 120 up to 128 one AES call per block confidentiality and authenticity lost OpenPGP, Mosh
Ascon-AEAD128 128 128 128 320-bit permutation plaintexts exposed; integrity holds small devices
AEGIS-128L / 256 128 / 256 128 / 256 128 or 256 AES round function XOR of plaintexts leaks libsodium

Sizes are in bits.

How it works

AES-GCM

McGrew and Viega (2004); NIST SP 800-38D (2007). AES in counter mode encrypts. GHASH evaluates the associated data, the ciphertext and their lengths as a polynomial at H = AES(K, 0¹²⁸) in GF(2¹²⁸), and AES of the first counter block masks the result into the tag. With AES and carry-less multiply instructions it is very fast, and TLS 1.3 makes TLS_AES_128_GCM_SHA256 mandatory to implement.

  • A repeated nonce is fatal. The XOR of the two plaintexts leaks, and the two tags give an equation in H, which lets the attacker forge under that key (Joux, 2006). In 2016 Böck and others found 184 HTTPS servers repeating GCM nonces.
  • Random nonces wear out. SP 800-38D allows at most 2³² messages per key with random 96-bit nonces, which keeps the chance of a repeat near 2⁻³³. A counter has no such limit; TLS 1.3 XORs the record number into a fixed IV.
  • Up to 2³⁹ − 256 bits, about 64 GB, per message.

ChaCha20-Poly1305

Bernstein's ChaCha20 stream cipher with his Poly1305 one-time authenticator. Adam Langley's 2013 draft brought it to TLS; RFC 7539 (2015), now RFC 8439 (2018), is the spec. ChaCha20 block 0 for the key and nonce gives a fresh Poly1305 key, the plaintext is XORed with the keystream from block 1 on, and Poly1305 tags the padded associated data, the padded ciphertext and the two lengths. Up to about 256 GB per message.

It exists because AES is only fast when the CPU has AES instructions. ChaCha20 is fast in plain software and naturally constant-time, so it wins on phones, embedded devices and older servers. TLS 1.3, WireGuard and OpenSSH all offer it; OpenSSH's chacha20-poly1305@openssh.com (2014) is its own variant that also encrypts the packet length. A repeated nonce gives away the Poly1305 key for that nonce, as the Universal hash MACs page shows. XChaCha20-Poly1305 has a 192-bit nonce, so random nonces never collide in practice; see ChaCha.

AES-GCM-SIV

Gueron and Lindell (CCS 2015); RFC 8452 (2019). Each nonce first derives its own authentication and encryption keys. POLYVAL, a little-endian twin of GHASH, runs over the associated data and the plaintext; AES of that value, with the nonce mixed in, is the tag, and the tag is also the starting counter for AES-CTR. So a repeated nonce only shows whether two messages were equal. The price is two passes: encryption can't start until the whole message is in. RFC 8452 allows 2³² random-nonce messages of up to 8 GB per key, or 2⁴⁸ of up to 32 MB.

AES-CCM

Whiting, Housley and Ferguson wrote it for Wi-Fi in 2002; RFC 3610 (2003) and SP 800-38C (2004). A CBC-MAC over the nonce, the length, the associated data and the plaintext, then AES-CTR over the plaintext and the MAC, all under one key. Two AES calls per block, the length must be known up front, and it only ever runs AES forwards, which keeps chips small. The nonce is 7 to 13 bytes, the tag 4 to 16. WPA2 and WPA3 (CCMP), Bluetooth LE and IEEE 802.15.4 (Zigbee, Thread) use it, and TLS 1.3 defines two CCM suites.

AES-OCB

Rogaway, Bellare, Black and Krovetz (CCS 2001); RFC 7253 (2014) has OCB3 from 2011. Each block is XORed with a secret offset, encrypted and XORed again, and an encrypted checksum of the plaintext gives the tag: about one AES call per block, parallel and in one pass. OCB was patented and licensed for years; Rogaway has since put it in the public domain and let the patents lapse. OCB2 (2004) was broken in 2018; OCB3 is a different design and isn't affected. OpenPGP (RFC 9580, 2024) makes OCB mandatory, and Mosh encrypts with AES-128-OCB3.

AEGIS

Wu and Preneel (SAC 2013). AEGIS-128 shared the high-performance slot of the CAESAR final portfolio (2019) with OCB, and RFC 10032 (September 2026) specifies AEGIS-128L, AEGIS-256 and the multi-lane 128X and 256X. The state is eight (128L) or six (256) AES blocks, and each message block goes in with one AES round per state block. There is no key schedule. It beats AES-GCM by a wide margin on CPUs with AES instructions. AEGIS-128L takes 2⁴⁸ random-nonce messages per key and AEGIS-256 has no practical limit. RFC 10032 expects it to commit to the key (2⁶⁴ work with a 128-bit tag, 2¹²⁸ with 256) as long as the attacker can't choose the associated data. libsodium ships it.

Ascon

Dobraunig, Eichlseder, Mendel and Schläffer submitted Ascon to CAESAR in 2014; it was the first choice for lightweight use in the final portfolio (2019). NIST picked it in February 2023 at the end of its lightweight cryptography project, and SP 800-232 (August 2025) is the standard, aimed at sensors and embedded chips where AES is too big or too slow.

Function Job Sizes Security
Ascon-AEAD128 AEAD 128-bit key, nonce and tag 128
Ascon-Hash256 hash 256-bit output 128
Ascon-XOF128 extendable output any length up to 128
Ascon-CXOF128 XOF with a customization string any length up to 128
  • One 320-bit permutation runs everything: five 64-bit words, a 5-bit S-box and XOR-and-rotate mixing.
  • AEAD is a duplex: load a constant, the key and the nonce, run 12 rounds and XOR the key in again. Absorb associated data and plaintext 128 bits at a time with 8 rounds in between. At the end mix the key in, run 12 rounds, and the tag is the last 128 bits XOR the key.
  • Hash and XOF are a plain sponge with a 64-bit rate and 12 rounds.
  • SP 800-232 starts from the submission's Ascon-128a but switched to little-endian byte order and new initial values, so old test vectors don't match.
  • At most 2⁵⁴ bytes per key. Tags may be cut to 32 bits, below 64 only after a risk analysis. An optional nonce-masking mode XORs a second 128-bit key into the nonce, for better security across many keys.
  • A repeated nonce exposes the plaintexts, but integrity holds as long as no nonce and associated data pair repeats more than 2⁸ times.

When to use it

  • AES-GCM where the CPU has AES instructions (most servers, laptops and phones), with counter nonces the way TLS does it. See AES for the block-cipher side.
  • ChaCha20-Poly1305 in pure software or when you want simpler constant-time code. The two are interchangeable in TLS 1.3.
  • Random or untrusted nonces, such as many machines sharing a key or VMs restored from snapshots: AES-GCM-SIV, XChaCha20-Poly1305 or AEGIS-256.
  • Small hardware: Ascon-AEAD128, or AES-CCM where Wi-Fi, Bluetooth or Zigbee call for it.
  • Use the AEAD interface, never raw ChaCha20 or AES-CTR alone. Encryption without the tag leaves you open to tampering.

Example (Python)

With PyCA cryptography:

import os
from cryptography.hazmat.primitives.ciphers.aead import ChaCha20Poly1305

key = ChaCha20Poly1305.generate_key()   # 32 bytes
aead = ChaCha20Poly1305(key)

nonce = os.urandom(12)                   # 96-bit, unique for every message
header = b"v1|message-id-42"             # associated data: authenticated, not encrypted

ct = aead.encrypt(nonce, b"secret data", header)
pt = aead.decrypt(nonce, ct, header)     # raises if the tag or header don't match

AESGCM, AESGCMSIV, AESCCM and AESOCB3 take the same encrypt(nonce, data, associated_data) calls. This needs the library and wasn't run for this page. The two halves of ChaCha20-Poly1305 run from the standard library on the ChaCha and Universal hash MACs pages.

Security notes

  • Never reuse a nonce with the same key. GCM-SIV survives it, but don't plan on that. Use a counter, or random nonces within the limits above. See Why does randomness matter.
  • Never use unverified plaintext. Decryption either returns the plaintext or fails. APIs that stream out plaintext before the tag is checked lose the protection; RFC 8452 and RFC 10032 forbid it.
  • Rekey before the limits. TLS 1.3 asks for a new key after about 2²⁴·⁵ full records with AES-GCM.
  • Most AEADs don't commit to the key. With GCM or ChaCha20-Poly1305 one ciphertext can be built to decrypt under two keys. Dodis and others used that in 2018 to get abusive images past Facebook Messenger's abuse reporting, and it lets an attacker test many passwords at once against password-derived keys (partitioning oracles, 2021).
  • Short tags are forgeable. 32- or 64-bit tags only where the protocol caps failed attempts.
  • Lengths leak. Pad if the length gives something away.

See also

References

Weaker sources: libsodium documentation for AEGIS in libsodium (since version 1.0.19).