AEAD and AES-256-GCM: How Your Messages Stay Tamper-Proof

Encryption alone does not keep a message safe. A scheme that only scrambles your words can still be silently altered in transit — flip a bit here, truncate a block there — and the recipient has no way to know the plaintext that comes out is not the plaintext that went in. Confidentiality answers “can an eavesdropper read this?” It says nothing about “did this arrive exactly as sent, from the party I think sent it?” That second question is integrity, and for a messenger it matters just as much. The construction that answers both at once is Authenticated Encryption with Associated Data, or AEAD, and the specific algorithm RVNT uses for every message body is AES-256-GCM. This post is about what AEAD actually guarantees, why the “associated data” part — your routing header, authenticated but deliberately left unencrypted — is the clever bit, and where the sharp edges are.

Why “encrypt” was never enough

For decades, encryption and authentication were treated as separate jobs, often bolted together by hand. Developers would encrypt with one primitive and then compute a separate Message Authentication Code (MAC) over the result. Done carefully — encrypt-then-MAC — this works. Done in any of the other plausible orderings, or with the MAC covering the wrong bytes, it fails in subtle, exploitable ways. The history of TLS is partly a history of padding-oracle attacks and MAC-ordering mistakes that turned “encrypted” channels into decryption oracles for a patient attacker.

The lesson the field absorbed is that confidentiality and integrity should be delivered by one primitive, designed together, with one key and one well-defined interface. That is precisely what RFC 5116, An Interface and Algorithms for Authenticated Encryption, standardizes. It defines AEAD as a single operation that “encrypts plaintext for confidentiality while simultaneously authenticating both the encrypted data and additional unencrypted information,” and notes the approach “provides advantages in efficiency and security, and promotes the reuse of crypto implementations.” One call in, one call out, both properties guaranteed — no room to wire it up wrong.

An AEAD scheme has two outputs that matter: the ciphertext (your message, scrambled) and an authentication tag (a short, unforgeable fingerprint over everything the scheme protects). Decryption recomputes the tag and refuses to return any plaintext if it does not match.

That refusal is the whole point. With AEAD, a tampered message does not decrypt to garbage you have to notice — it does not decrypt at all.

The “AD” in AEAD: authenticated, not encrypted

The part of AEAD that trips people up is the associated data — the AD. Alongside the plaintext it encrypts, an AEAD algorithm accepts a second input that it authenticates but does not encrypt. That data travels in the clear, but it is bound into the same authentication tag as the ciphertext. Change one byte of it and the tag check fails exactly as if you had tampered with the ciphertext itself.

Why would you ever want data you are protecting to stay readable? Because some metadata has to be readable for the message to be delivered or decrypted at all. The classic example is a packet header: a router needs the destination to forward the packet, so encrypting it would be self-defeating — but you still want to detect if an attacker rewrites it. Associated data is the mechanism for “this field must stay visible, but it must not be forgeable.”

RVNT uses this in a very concrete place: the Double Ratchet message header. Every ratchet message carries a small header — the sender’s current ratchet public key, the previous chain length, and the message number. The recipient needs those fields before it can pick the right decryption key, so they cannot themselves be encrypted under that key (a chicken-and-egg problem). Instead, RVNT serializes the header and passes it as the AAD when it encrypts the body:

ciphertext = AES-256-GCM(
    key:   message_key,
    nonce: random_96bit,
    aad:   serialize(header),   // authenticated, NOT encrypted
    data:  compressed_plaintext
)

The header is therefore plaintext relative to the ratchet layer but tamper-evident: forge or alter any field and the GCM tag mismatches, so the message is rejected rather than decrypted with the wrong key or silently re-routed. This is an honest tradeoff, and worth stating plainly: an attacker who could read a raw ratchet message would see those routing fields. Hiding who is talking and when is not the header’s job — that is handled by separate layers (see our note on metadata privacy and sealed sender, which wraps the entire ratchet message, header included, inside an encrypted envelope). The AAD’s job is narrower and it does it completely: nobody gets to tamper with routing information undetected.

How AES-256-GCM actually builds the guarantee

AES-256-GCM is the AEAD scheme RVNT uses for message bodies, and it is the workhorse of modern secure transport generally — it is one of the four algorithms RFC 5116 registers, and TLS leans on it heavily. It is specified in full by NIST SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC (November 2007). The name decomposes into the pieces:

Component	Role
AES-256	The block cipher, with a 256-bit key, providing confidentiality
Counter (CTR) mode	Turns the block cipher into a stream cipher by encrypting a counter
Galois field MAC (GMAC)	Computes the authentication tag over ciphertext + AAD

In plain terms: GCM uses AES in counter mode to produce a keystream that is XORed with the plaintext (that is the encryption), and in parallel runs the ciphertext and the associated data through a fast arithmetic operation in the Galois field GF(2¹²⁸) to produce a 128-bit authentication tag (that is the authentication). Both happen in one pass, both depend on the same key, and the tag covers the AAD even though the AAD is never encrypted. On decryption, the receiver recomputes the tag over the ciphertext and AAD it actually received; if it does not match the tag that arrived, it returns an error and zero plaintext.

The 256-bit key is the post-quantum-conscious choice. A 128-bit symmetric key offers a comfortable classical margin, but Grover’s algorithm on a future quantum computer would, in principle, halve the effective security of a brute-force key search. AES-256 keeps a roughly 128-bit margin even under that pessimistic model — which is why it pairs naturally with RVNT’s other post-quantum measures like ML-KEM-768 in the key exchange. The body cipher should not be the weak link when the rest of the stack is bracing for harvest-now, decrypt-later.

The nonce: GCM’s one unforgiving rule

GCM’s speed and elegance come with a single non-negotiable condition, and it is worth dwelling on because getting it wrong is the most common way AES-GCM deployments are broken. Every encryption under a given key must use a unique nonce (the 96-bit “number used once” that seeds the counter). RFC 5288, which defines GCM cipher suites for TLS, puts it bluntly: “AES-GCM security requires that the counter is never reused,” and “failure to meet this uniqueness requirement can significantly degrade security.”

That understates it. Reuse a nonce with the same key on two different messages and an attacker can XOR the two ciphertexts to strip the keystream, recovering relationships between the plaintexts. Worse, nonce reuse leaks the GMAC authentication key itself, which lets an attacker forge tags — collapsing both the confidentiality and the integrity guarantee at once. There is no graceful degradation here; the failure is total. (For the formal treatment of just how bad nonce-misuse is in AES-GCM, see Böck, Zauner, Devlin, Somorovsky, and Jovanovic’s Nonce-Disrespecting Adversaries, which found and exploited reused nonces in live HTTPS servers.)

RVNT defends the nonce invariant structurally rather than hoping nobody makes a mistake:

• Each message key is used exactly once, then zeroed. Because the Double Ratchet derives a fresh single-use key for every message, there is no long-lived key under which two nonces could collide.
• Nonces are 96 bits of CSPRNG output drawn from the operating system, generated per message.
• Every chain step and every DH ratchet step replaces the key material entirely, so the (key, nonce) space is never revisited.

The architecture makes nonce reuse not merely discouraged but hard to express. That is the right posture for a property where a single slip is catastrophic.

What AEAD does and does not promise

It is worth being precise about the boundary of the guarantee, because AEAD is sometimes oversold. Here is the honest accounting for a message protected by AES-256-GCM:

• Confidentiality of the body — an eavesdropper cannot read the plaintext. ✓
• Integrity of the body — any modification to the ciphertext is detected and the message rejected. ✓
• Integrity of the associated data — any modification to the authenticated header is detected. ✓
• Confidentiality of the associated data — not provided by AEAD. The AAD is readable by design.
• Replay protection, ordering, sender identity — not provided by AEAD on its own. These come from the protocol around it.

That last line is the one to internalize. AEAD authenticates that a holder of the key produced this exact ciphertext-plus-header; it does not, by itself, stop someone from replaying a valid old message or prove which human is on the other end. RVNT layers those properties in: replay is blocked because each message key is deleted after one use (a replayed message has no surviving key to decrypt it), and end-to-end authentication plus forward secrecy come from the ratchet and key-exchange machinery, not from GCM.

So when we say your messages are “tamper-proof,” the precise claim is this: the body cannot be read or altered without the per-message key, and the routing header cannot be altered without breaking the tag — even though it is intentionally left readable so the protocol can function. AEAD gives you confidentiality and integrity in one well-specified primitive; the surrounding design decides what gets the encryption treatment and what only needs the authentication treatment. Getting that division right — body encrypted, header authenticated as associated data — is what lets a message be both deliverable and tamper-evident at the same time.

RVNT is pre-release and has not yet been independently audited; the protocol specification documents the construction as implemented so it can be reviewed in full. The primitives here — AES-256-GCM under the NIST and RFC standards above — are about as battle-tested as symmetric cryptography gets. The work, as always, is in composing them without leaving a seam.