AEAD
Also known as: Authenticated Encryption with Associated Data, authenticated encryption, AEAD cipher
AEAD stands for Authenticated Encryption with Associated Data, a class of cipher that delivers confidentiality and integrity in one operation. It encrypts the plaintext and produces an authentication tag covering both the ciphertext and optional associated data. The associated data is authenticated but left in plaintext, so any tampering with either part makes decryption fail outright.
Plain encryption keeps a message secret but says nothing about whether it arrived unaltered. Bolting a separate MAC on afterward is famously error-prone: get the order wrong (encrypt-then-MAC versus MAC-then-encrypt) and you open padding-oracle and forgery attacks. AEAD solves this by making encryption and authentication a single, hard-to-misuse primitive. You hand it a key, a unique nonce, the plaintext, and optionally some associated data; it returns ciphertext plus a short authentication tag (typically 128 bits).
The associated data is the clever part. It is data you need to authenticate but not hide — packet headers, sequence numbers, routing fields, version bytes. The cipher folds it into the tag computation but never encrypts it, so it stays readable on the wire while still being protected against forgery. Change one bit of the ciphertext, the tag, or the associated data and the receiver's tag check fails, so the whole message is rejected before any plaintext is exposed.
The standard interface is defined in RFC 5116 (2008). The dominant AEAD construction is AES-256-GCM; ChaCha20-Poly1305 is the common alternative. One ironclad rule applies to all of them: never reuse a nonce under the same key, or both secrecy and integrity collapse. See end-to-end encryption for where AEAD sits in the stack.
How it works
Encryption: seal(key, nonce, associated_data, plaintext) → (ciphertext, tag). The cipher encrypts the plaintext (in GCM, via counter mode) and computes a single authentication tag over both the ciphertext and the associated data.
Decryption: open(key, nonce, associated_data, ciphertext, tag) → plaintext | FAIL. The receiver recomputes the tag and compares it in constant time. If the supplied ciphertext, associated data, nonce, or tag has been altered, the comparison fails and no plaintext is returned.
The nonce must be unique per key. The associated data is covered by the tag but never encrypted, which is exactly why it can carry plaintext routing information that must still be tamper-evident.
How RVNT uses AEAD
RVNT uses AEAD everywhere sensitive bytes move or rest. Every Double Ratchet message is sealed with AES-256-GCM, and the ratchet header (DH public key, previous-chain length, message number) rides along as associated data — authenticated but, by design, plaintext. A forged or altered header fails the tag check and the message is dropped. File chunks use the same AEAD under a separate content key, and the local database is protected by SQLCipher's authenticated encryption.
Frequently asked questions
What does 'associated data' mean in AEAD?
Associated data is extra information that is authenticated but not encrypted. It travels in plaintext alongside the ciphertext, but the authentication tag covers it, so any tampering is detected. Typical uses are headers, sequence numbers, and routing fields that intermediate systems must read.
Is AEAD better than encrypting and then adding a MAC?
Generally yes. AEAD packages encryption and authentication into one well-defined primitive, which removes the common, dangerous mistakes of composing them by hand (such as choosing the wrong order). It is also usually faster, since modern AEAD ciphers compute the tag in the same pass.
Does AEAD encrypt the headers it authenticates?
No. That is the whole point of associated data: it is authenticated but left in plaintext. If you need the header hidden too, you must encrypt it separately or wrap the entire message in another encrypted layer, as RVNT does with sealed sender.
Every definition here describes something RVNT actually ships — a post-quantum, end-to-end-encrypted, peer-to-peer messenger with no phone number and no servers.