It is tempting to think of encryption as a single guarantee: scramble the data so nobody can read it. But confidentiality is only half of what secure communication needs. The other half is integrity — assurance that the ciphertext you received is exactly what the sender produced, not something an attacker altered in transit. Plain encryption provides the first and says nothing about the second.
Authenticated Encryption with Associated Data — AEAD — is the modern answer. It bundles confidentiality and integrity into one primitive, with a clean interface that is hard to misuse. Every serious protocol designed in the last fifteen years uses it, and for good reason.
The Problem With Encryption Alone
Consider a stream cipher, which encrypts by XOR-ing your plaintext with a pseudorandom keystream. It is genuinely confidential — without the key, the output looks like noise. But XOR has a dangerous property: if an attacker knows or guesses part of the plaintext, they can flip specific bits in the ciphertext and cause exactly corresponding bit-flips in the decrypted result. They cannot read the message, but they can change it in predictable ways.
A classic illustration: a banking message encrypted as "transfer $100" might be silently mutated into "transfer $900" by an attacker who knows the format, without ever decrypting it. The receiver decrypts garbage-free-looking plaintext and acts on a forged instruction.
Hiding the contents of a message is a different goal from proving it wasn't altered. A cipher can perfectly conceal data while leaving it completely malleable. You need a separate mechanism — a message authentication code — to detect tampering, or an AEAD construction that builds both in.
How AEAD Works
An AEAD scheme takes four inputs and produces two outputs. The inputs are the secret key, a nonce (a number used once), the plaintext, and optional associated data. The outputs are the ciphertext and an authentication tag — typically 128 bits.
On decryption, the receiver supplies the key, nonce, ciphertext, associated data, and the tag. The algorithm recomputes the tag and compares it to the one received. If they do not match — even by a single bit — decryption fails and returns nothing. The receiver never sees tampered plaintext, because the construction refuses to hand it over.
What is associated data?
The "AD" in AEAD is data that must be authenticated but not encrypted — packet headers, message metadata, routing information that needs to stay readable but must not be forgeable. AEAD binds the ciphertext to that context. An attacker cannot lift a valid ciphertext and replay it under a different header, because the header is folded into the tag.
The Two Workhorses: AES-GCM and ChaCha20-Poly1305
Two AEAD constructions dominate modern use. Both are mandatory cipher suites in TLS 1.3.
| Property | AES-256-GCM | ChaCha20-Poly1305 |
|---|---|---|
| Type | Block cipher (AES) in Galois/Counter Mode | Stream cipher (ChaCha20) + Poly1305 MAC |
| Hardware acceleration | Very fast with AES-NI CPU instructions | Fast in pure software, no special hardware |
| Best on | Modern desktops/servers with AES-NI | Mobile and embedded chips lacking AES-NI |
| Nonce sensitivity | Catastrophic on reuse | Catastrophic on reuse |
The practical rule of thumb: AES-GCM wins where the CPU has dedicated AES instructions; ChaCha20-Poly1305 wins on devices without them, where AES in software is both slower and more prone to timing side-channel leaks. This is why mobile browsers and apps frequently prefer ChaCha20.
The Cardinal Sin: Nonce Reuse
Both algorithms share a brutal failure mode. The nonce must never repeat under the same key. A nonce is not secret — it can be sent in the clear — but it must be unique per encryption.
Reuse a nonce with AES-GCM and you do not just leak a little. You can leak the relationship between two plaintexts, and worse, you can leak the authentication key itself — letting an attacker forge valid tags for arbitrary messages. The integrity guarantee collapses entirely.
This is not theoretical. Nonce-reuse bugs have appeared in shipping products, often when a counter resets after a crash or when a random nonce space is too small. The defenses are to use a strictly increasing counter, or to adopt a nonce-misuse-resistant scheme like AES-GCM-SIV, which degrades gracefully instead of catastrophically if a nonce repeats. Generating unique nonces also depends on a sound source of randomness and careful state management.
Encrypt-then-MAC and the Death of Bolt-On Integrity
Before AEAD became standard, developers combined a cipher and a separate MAC by hand — and frequently got the order wrong. The secure ordering is encrypt-then-MAC: encrypt the plaintext, then authenticate the ciphertext. The insecure alternatives (MAC-then-encrypt, encrypt-and-MAC) opened the door to padding-oracle attacks that plagued older TLS versions for years.
AEAD removes the footgun by making the correct construction the only construction. The developer gets one function that does both, in the right order, with the tag check built into decryption. Fewer choices means fewer ways to be wrong — a recurring theme in well-designed cryptographic APIs.
Where This Touches You
Every HTTPS connection you make negotiates an AEAD cipher. Your encrypted backups, your VPN tunnel (WireGuard uses ChaCha20-Poly1305), your messaging app's per-message encryption — all of them rely on authenticated encryption to ensure that what you receive is both private and unmodified.
At Haven, AEAD primitives protect data at rest and in transit, working alongside the key agreement and ratcheting handled by the MLS protocol. The principle is the same throughout: secrecy without integrity is a false sense of safety, and AEAD is how the modern stack delivers both at once.