Authenticated Encryption: AES-GCM and ChaCha20-Poly1305

Authenticated Encryption (AE) solves a fundamental problem: traditional encryption only provides confidentiality — it keeps data secret — but it does not verify whether the ciphertext has been tampered with. An attacker could flip bits in ciphertext and the receiver would decrypt garbage without knowing it was modified. Authenticated Encryption with Associated Data (AEAD) adds an integrity and authenticity guarantee simultaneously, producing both encrypted ciphertext and an authentication tag that detects any modification.

AES-GCM (Galois/Counter Mode) combines two components: AES-CTR (Counter Mode) for encryption and GMAC (Galois Message Authentication Code) for integrity. AES-CTR generates a keystream by encrypting a counter value and XOR-ing it with plaintext — this makes encryption parallelizable, unlike CBC mode. GMAC computes an authentication tag over the ciphertext and any associated data. The resulting tag (128 bits) travels alongside the ciphertext; a single bit change invalidates the tag.

AES-GCM requires a nonce (number used once), typically 96 bits (12 bytes). The nonce must be unique for every single encryption operation with the same key — it does not need to be secret, but it must never repeat. Nonce reuse in AES-GCM is catastrophic: if two messages are encrypted with the same key and nonce, an attacker can XOR the ciphertexts to cancel the keystream, potentially recovering both plaintexts. This vulnerability is sometimes called 'nonce misuse' and has caused real-world key recovery attacks.

When AES-GCM nonces are reused, the attacker can compute C1 XOR C2 = P1 XOR P2 (the XOR of both plaintexts), because the same keystream was used for both. Additionally, nonce reuse allows recovering the authentication key H, which means the attacker can forge valid authentication tags for arbitrary messages — completely breaking both confidentiality and integrity. Systems like Sony PS3 suffered this exact attack. The defense is randomized nonces (generated with a CSPRNG) or a deterministic counter that never resets.

ChaCha20-Poly1305 is the other AEAD cipher mandated in TLS 1.3. ChaCha20 is a stream cipher designed by Daniel Bernstein that generates a keystream using add-rotate-XOR (ARX) operations — no lookup tables, completely constant time, and extremely fast on CPUs without AES hardware acceleration. Poly1305 is a one-time MAC (message authentication code) that computes the authentication tag over the ciphertext. Together, they provide equivalent security to AES-GCM but are significantly faster on mobile and IoT devices.

Modern x86 and ARM64 desktop/server processors include AES-NI hardware instructions that make AES-GCM extremely fast. However, many mobile and IoT processors lack AES-NI, making software AES-GCM relatively slow. ChaCha20-Poly1305 was designed to be fast in software using simple arithmetic operations, giving mobile devices comparable performance without hardware acceleration. Google added ChaCha20-Poly1305 to TLS as an alternative precisely for Android devices, and it is now a first-class cipher suite in TLS 1.3.

The 'AD' in AEAD stands for Associated Data — plaintext metadata that is authenticated but not encrypted. This allows you to authenticate data that must remain readable (like packet headers or record type fields) while still protecting it from tampering. In TLS 1.3, the record header bytes are included as associated data in the AEAD computation. If an attacker modifies the header (e.g., changes the record length), the authentication tag verification fails and the connection is terminated.

Before AEAD became standard, cryptographers recommended Encrypt-then-MAC (EtM): encrypt the plaintext, then compute a MAC over the ciphertext. This is secure but requires two separate operations with two separate keys. AEAD schemes like AES-GCM combine both operations with a single key, reducing implementation complexity and eliminating a whole class of padding oracle attacks that plagued MAC-then-Encrypt (MtE) — the ordering used in older TLS versions (CBC + HMAC). TLS 1.3 using AEAD avoids these problems entirely.

Both AES-128-GCM and AES-256-GCM are approved by NIST and considered secure against classical computers. AES-128 offers 128-bit security with slightly faster performance; AES-256 offers 256-bit security, providing a larger margin against future cryptanalysis and quantum threats. For most applications today, AES-128-GCM is sufficient, but government classified systems (NSA Suite B) require AES-256. TLS 1.3 offers both, and servers can prioritize based on their security policy.

When decrypting AEAD ciphertext, the receiver must verify the authentication tag before decrypting. The process is: recompute the expected tag from the received ciphertext, key, and nonce; compare it to the received tag using a constant-time comparison function; only if they match, proceed with decryption. Constant-time comparison is critical — if the comparison short-circuits on the first mismatched byte, an attacker can mount a timing side-channel attack to forge valid tags byte by byte. Any AEAD library that uses early-exit comparison is vulnerable.

AEAD algorithms are ubiquitous in modern security: TLS 1.3 uses AES-GCM and ChaCha20-Poly1305 for all record encryption; WireGuard VPN uses ChaCha20-Poly1305 exclusively; Signal Protocol uses it for message encryption; QUIC protocol (the basis of HTTP/3) uses AES-GCM. When you see a cipher suite like TLS_AES_256_GCM_SHA384, the SHA384 refers to the HKDF hash function for key derivation, not the integrity mechanism — the GCM tag handles integrity.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: AEAD algorithms provide confidentiality and integrity simultaneously via an authentication tag that detects any ciphertext modification, AES-GCM nonce reuse is catastrophic — allowing keystream recovery and authentication key forgery — so nonces must be unique per encryption, and ChaCha20-Poly1305 is the performance-efficient alternative to AES-GCM for devices lacking hardware AES acceleration. Next up we explore key derivation functions for securing passwords.