Symmetric Ciphers and Modes of Operation

A block cipher (AES, 3DES) transforms a fixed-size chunk of plaintext into ciphertext using a key. AES operates on 128-bit blocks with 128-, 192-, or 256-bit keys. The block cipher itself is a permutation — given the same block and key, you always get the same output. That's a problem, not a feature.

A stream cipher (ChaCha20, RC4) generates a keystream from a key and a nonce, then XORs it with the plaintext byte-by-byte. Stream ciphers are faster on hardware without AES-NI and have no block-alignment issues. CTR mode turns AES into a stream cipher. The distinction blurs in practice — what matters is the mode wrapping the primitive.

Electronic Codebook (ECB) encrypts each block independently: $C_i = E_K(P_i)$. This looks simple and parallelizable — it's also broken for any real data.

The penguin attack: encrypt a bitmap image with AES-ECB and the block boundaries in the image become visible, because identical 16-byte plaintext blocks produce identical ciphertext blocks. No attacker needs the key; they just observe that $C_i = C_j$ implies $P_i = P_j$.

ECB also enables cut-and-paste attacks: rearranging ciphertext blocks rearranges the corresponding plaintext blocks. Never use ECB for anything except a single isolated block (e.g., wrapping another key with AES-KW, which adds its own integrity check).

Cipher Block Chaining (CBC) XORs each plaintext block with the previous ciphertext block before encrypting:

$C_i = E_K(P_i \oplus C_{i-1}), \quad C_0 = \text{IV}$

The IV must be unpredictable (random) per message — not secret, but random. If an attacker can predict the IV before choosing plaintext, they can mount chosen-plaintext attacks (as in BEAST against TLS 1.0).

CBC encryption is sequential (can't parallelize), but decryption is parallelizable. It also requires PKCS#7 padding to fill the last block — and padding oracles (Vaudenay 2002, POODLE) have broken countless CBC-MAC schemes. If you use CBC, always pair it with a separate MAC (Encrypt-then-MAC, not MAC-then-Encrypt).

Counter (CTR) mode generates keystream blocks by encrypting a counter:

$C_i = P_i \oplus E_K(\text{nonce} \| i)$

The nonce (number used once) plus counter fills a 128-bit block. Encryption and decryption are identical, both are fully parallelizable, and there's no padding needed. CTR is fast and simple.

The catastrophic gotcha: reuse a nonce with the same key and you have $C_1 \oplus C_2 = P_1 \oplus P_2$, which destroys confidentiality completely. Attackers can recover both plaintexts from known plaintext fragments. This is the "two-time pad" problem — CTR is a stream cipher and stream ciphers must never reuse key+nonce pairs. No exceptions.

Galois/Counter Mode (GCM) = CTR confidentiality + GHASH authentication tag. It is the canonical AEAD (Authenticated Encryption with Associated Data) mode for AES.

GCM produces a 128-bit authentication tag alongside the ciphertext. It also authenticates associated data (AAD) — headers, nonces, packet metadata — that travel in plaintext but must not be tampered with. Any bit flip in ciphertext or AAD causes tag verification to fail before any plaintext is returned.

Nonce reuse in GCM is worse than in CTR: an attacker who sees two ciphertexts under the same key+nonce can recover the authentication key (the GHASH key), allowing them to forge arbitrary messages forever. Use a 96-bit random nonce; at 2^32 messages, birthday collision probability exceeds 1%.

For modern systems, AES-256-GCM is the answer unless you have a specific hardware constraint.

AEAD is an interface, not an algorithm. The contract: seal(key, nonce, plaintext, aad) → (ciphertext, tag), and open(key, nonce, ciphertext, tag, aad) → plaintext or error. The critical rule: never release plaintext until the tag passes. MAC-then-decrypt implementations that return partial plaintext before verifying the tag are the padding oracle of AEAD.

Alternatives to AES-GCM worth knowing:

• ChaCha20-Poly1305: Preferred when hardware AES acceleration isn't available (mobile, IoT). Used in TLS 1.3.
• AES-SIV (RFC 5297): Nonce-misuse-resistant — nonce reuse leaks only whether plaintexts are equal, not the plaintext itself.
• AES-GCM-SIV: Combines AES-GCM performance with SIV's nonce-misuse resistance.

Using cryptography (pyca) — the right library for Python:

from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

key = AESGCM.generate_key(bit_length=256)  # 32 bytes, from /dev/urandom
aead = AESGCM(key)

nonce = os.urandom(12)          # 96-bit nonce, never reuse with same key
aad = b"user_id=42,version=1"  # authenticated but not encrypted
plaintext = b"transfer $1000 to Alice"

ciphertext = aead.encrypt(nonce, plaintext, aad)
# ciphertext includes the 16-byte GCM tag appended

recovered = aead.decrypt(nonce, ciphertext, aad)
# raises InvalidTag if anything was tampered with
assert recovered == plaintext

Send (nonce, ciphertext) together; nonce is not secret. Store key separately — in a KMS or HSM, not next to the ciphertext.

Getting nonces right is the hardest part of symmetric encryption in practice:

• Random 96-bit nonce: Simple, works well up to ~2^32 messages per key (birthday bound). Use os.urandom(12) or equivalent CSPRNG.
• Counter + synchronized state: Eliminates birthday collision risk, but requires durable state across crashes and distributed nodes. Fencing tokens or sequence numbers in a DB work.
• Random 192-bit nonce (XSalsa20, XChaCha20): Extended nonces make random-per-message safe for far more messages — ~2^96 messages before 1% collision risk.

Key rotation is the backstop: rotate keys well before hitting birthday bounds. A key used for 2^32 GCM messages has ~1% chance of nonce collision — at that point, the encryption scheme's security guarantees are gone regardless of how random your nonces are.