Symmetric Encryption and AEAD

TL;DR: Symmetric ciphers such as AES use the same secret key to encrypt and decrypt. Encryption alone hides data but lets an attacker flip bits in the ciphertext undetected, so modern systems use authenticated encryption with associated data (AEAD): AES-GCM or ChaCha20-Poly1305. AEAD outputs ciphertext plus a tag, and decryption fails if anything was changed, including unencrypted "associated data" such as a header. The rule you cannot break: never reuse a nonce with the same key. And remember that encryption moves the problem to key management.

Before you read

Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.

1. 1A cookie holds the text 'role=user' encrypted with AES in CTR mode, with no MAC. Can an attacker who cannot read the cookie change their role?

   Commit to a guess, then reveal

One key, both directions

Symmetric encryption uses a single secret key for both encryption and decryption. It is fast, which is why it protects nearly all bulk data: TLS traffic after the handshake, disk and database encryption, encrypted backups, and secrets in a vault. AES, standardised by NIST in 2001, is the dominant block cipher, with hardware support in most processors. ChaCha20 is a stream cipher that performs well on devices without AES hardware.

AES encrypts fixed 128-bit blocks. To encrypt anything longer, it is used in a mode, and modes are where the classic mistakes live.

• ECB encrypts each block independently, so identical plaintext blocks produce identical ciphertext blocks. Patterns in the data survive encryption. Never use it.
• CBC chains blocks together and needs an unpredictable IV. Without a separate MAC, it is vulnerable to padding oracle attacks, where error messages about bad padding let an attacker decrypt data byte by byte.
• CTR turns AES into a stream cipher: encrypt a counter to make a keystream, then XOR it with the plaintext. It is fast and parallel, and fully malleable without a MAC, as the drill above shows.

All three provide confidentiality only. Each is dangerous on its own.

Authenticated encryption

The fix is to authenticate the ciphertext so that any change is detected before plaintext is released. Older designs combined a cipher with a MAC, and the safe ordering was encrypt-then-MAC. Modern designs use an AEAD construction that does both in one primitive:

• AES-GCM: AES in counter mode plus the GHASH authenticator. The most widely deployed AEAD; used in TLS and most cloud services.
• ChaCha20-Poly1305: the ChaCha20 stream cipher plus the Poly1305 authenticator (RFC 8439). Common on mobile and in protocols such as WireGuard.

An AEAD encrypt operation takes a key, a nonce, the plaintext and optional associated data. It returns ciphertext and a tag. Associated data is authenticated but not encrypted: for example, a tenant ID or record ID. To reject a ciphertext moved between tenants, the decryptor must supply the tenant ID it expects from trusted authorization context. Trusting an attacker-editable AAD field stored beside the ciphertext permits the attacker to move both together.

Nonces: the rule that cannot bend

A nonce ("number used once") makes each encryption under the same key different. For AES-GCM the standard nonce is 96 bits. Reusing a nonce with the same key is catastrophic, not just weak:

• The two ciphertexts share a keystream, so XORing them yields the XOR of the two plaintexts, which often reveals both.
• For GCM specifically, nonce reuse can let an attacker recover the authentication key and forge valid tags for arbitrary messages.

Ways to stay safe:

• Generate nonces randomly with a cryptographic random generator, and rotate keys long before the random-collision risk becomes meaningful (NIST guidance limits random 96-bit nonces to about 2^32 encryptions per key).
• Or use a counter that is guaranteed never to repeat, which is hard across many machines.
• Or use a misuse-resistant mode such as AES-GCM-SIV (RFC 8452), which degrades gracefully if a nonce repeats.
• Better still, use a high-level library (libsodium, Tink, your cloud provider's encryption SDK) that handles nonces for you.

Worked example: a nonce budget

The 2^32 limit for random 96-bit nonces comes from NIST SP 800-38D, which caps the probability of any nonce repeating under one key at about one in four billion. It sounds enormous until you divide it by a throughput:

A service that uses one static AES-GCM key with random nonces at a million encryptions a second is past the safe limit before lunch. The fixes are designs, not tuning: derive a fresh data key per object, per file or per hour (envelope encryption does this naturally), use a construction with a larger nonce such as XChaCha20-Poly1305 with 192 random bits, or use AES-GCM-SIV where a repeated nonce leaks only whether two messages were identical.

Bind ciphertext to its context with associated data

AEAD modes authenticate an extra input, the associated data (AAD), that is not encrypted but must match at decryption. Use it to bind each ciphertext to where it belongs: the tenant ID, the table and column, the record ID. Without it, an attacker who can write to the database can move tenant A's encrypted social security number into tenant B's row, and it decrypts perfectly because the same key protects both. With the record and tenant in the AAD, the swapped ciphertext fails authentication.

Key commitment

AES-GCM and ChaCha20-Poly1305 do not commit to a key: it is possible to construct one ciphertext that decrypts validly under two different keys to two different plaintexts. That rarely matters when one party holds one key, but it does in systems where recipients use different keys for the same message, such as multi-recipient encrypted messaging or abuse-reporting schemes, where it has been used to show different content to different people. Where that applies, use a key-committing construction or add a commitment to the key alongside the ciphertext.

Encryption moves the problem to keys

Encryption converts a large secret (your data) into a small one (the key). Everything then depends on who can use that key. Encrypting a database with a key stored in the same database, or in an environment variable on every application server, protects against a stolen backup and against little else. Real designs hold keys in a key management service (KMS) or a hardware security module (HSM), use envelope encryption so that data keys are themselves encrypted by a master key that never leaves the KMS, and log every use. The envelope encryption question walks through that design.

Rotation, rewrapping and deletion are different operations

Envelope encryption separates the data encryption key (DEK) from the key encryption key (KEK) that wraps it. A KMS can keep the KEK inside its boundary while the application temporarily holds a plaintext DEK to encrypt or decrypt records. Protect process memory, crash dumps and key caches as well as the KMS policy.

AWS KMS rotation retains old material for decryption; it does not re-encrypt application data or replace generated data keys. After suspected key compromise, identify which layer leaked, revoke the caller's access, and plan replacement and data migration for that layer. A routine rotation checkbox is not incident containment.

For crypto-shredding, inventory wrapped key copies in backups, recovery mechanisms and plaintext caches. Deleting one wrapped-key row while an older backup still contains a usable copy does not erase the tenant's data. Verify the provider's deletion delay and test recovery failure before claiming erasure.

Misconceptions interviewers listen for

• "Encrypted means tamper-proof." Only with authenticated encryption; CBC and CTR alone are malleable.
• "A 96-bit random nonce never repeats." It does, with probability that becomes material after about 2^32 messages per key.
• "Nonce reuse in GCM reveals the key." It reveals the XOR of the plaintexts and lets an attacker recover the authentication key and forge messages; full plaintext recovery needs known plaintext.
• "Encrypting the column protects it from the application." The application holds or can use the key; encryption at rest protects against stolen storage and backups.
• "We'll delete the data by deleting the rows." Backups and replicas keep copies; destroying a per-tenant key (crypto-shredding) is often the only practical way to make them unreadable.

What if · interview follow-ups

Hold your answer as the constraints change

You are designing field-level encryption for a multi-tenant SaaS database that stores customer identity numbers, with a cloud KMS available. The interviewer changes one design choice at a time.

1. 1

   Start here

   What if every row is encrypted with one AES-GCM key and random 96-bit nonces, at about a million encryptions a second?

   Nudge meAnswer it out loud, then reveal

Revising, not practising? Show every answer

Primary references

References for the mechanisms discussed above, accessed 6 November 2026:

• AWS KMS rotation: what happens to existing data keys and ciphertext.

How this shows up in interviews

Interviewers ask "why is authenticated encryption the default?" and "what does nonce reuse break?" to see whether you know encryption and integrity are separate properties. The strong answer explains malleability with a concrete example, names AES-GCM or ChaCha20-Poly1305, mentions associated data as a way to bind context, and then turns to key management unprompted, because that is where real systems fail.

Say it in 30 seconds: "Symmetric encryption like AES uses one key both ways and is what protects bulk data. Plain modes like CTR or CBC hide data but are malleable, so you use AEAD, AES-GCM or ChaCha20-Poly1305, which adds a tag so any change to the ciphertext or the associated data makes decryption fail. Never reuse a nonce under the same key, because with GCM that leaks plaintext and lets attackers forge tags. And the real question is always who can use the key."

Check yourself

Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.

1. 1Why would you pass a user ID as associated data when encrypting that user's records with AES-GCM?

   Answer it, then reveal

2. 2A service encrypts millions of messages per day with one AES-GCM key and random 96-bit nonces, and has never rotated the key. What would you recommend?

   Answer it, then reveal

3. 3A service encrypts a million records a second under one AES-GCM key with random 96-bit nonces. Roughly how long until it exceeds NIST's 2^32 limit?

   Answer it, then reveal

4. 4What is associated data in an AEAD mode, and what attack does it stop?

   Answer it, then reveal