Encryption is usually described as "nobody else can read it." Give the definition of what a block-cipher mode of operation actually guarantees, and explain why a ciphertext an attacker can modify in a predictable way is insecure even when they can never read it.

## What a "mode of operation" is A block cipher is a keyed permutation on one fixed-size block — typically 128 bits. On its own it is not an encryption scheme: it can only turn 16 bytes into 16 bytes. A **mode of operation** is the construction that lifts that primitive into a scheme for messages of arbitrary length. The mode decides how blocks relate to each other (chaining, as in CBC), or whether the cipher is used to generate a keystream that is XORed with the plaintext (counter-style modes), how a final partial block is handled (padding, ciphertext stealing, or nothing at all in a stream-like mode), and whether the output is randomized by an initialization vector or nonce. The cipher is almost never the weak part. Essentially every real-world break in this area is a **mode-level or composition-level** failure, not a break of the underlying permutation. ## The property a mode actually provides The standard goal is **indistinguishability under chosen-plaintext attack (IND-CPA)**: an adversary who can have plaintexts of their choice encrypted still cannot tell which of two *equal-length* messages a challenge ciphertext corresponds to. Two things fall out of that definition that candidates routinely miss. First, *equal-length*. No conventional mode hides message length. Length alone can be the secret — a yes/no answer, an autocomplete suggestion, a compressed payload whose size depends on how much a guessed secret matched. Second, and more importantly, the definition says nothing whatsoever about what happens when the adversary **modifies** a ciphertext and submits it back. IND-CPA is a passive-reading property. It is not a property about tampering. ## Malleability, concretely Unauthenticated modes are *malleable*: a controlled change to the ciphertext produces a controlled change to the plaintext. - **Counter/stream-style modes.** Ciphertext = plaintext XOR keystream, byte-aligned. Flip ciphertext bit *i* and plaintext bit *i* flips. The attacker never learns the plaintext, but if they can guess the layout — a fixed-offset field, a serialized struct, `role=user`, a length prefix — they rewrite it exactly. No key needed. - **CBC.** Modifying a block of ciphertext turns the corresponding plaintext block into unpredictable garbage, but XORs your chosen delta into the *next* plaintext block. So the attacker spends one block of noise to gain bit-level control of the following block. - **All of them.** Whole blocks or records can be truncated, duplicated, reordered, or replayed from an older session, because nothing binds a ciphertext to its position, its record, or its point in time. ## "It will just decrypt to garbage and my parser will reject it" This is an argument that the attack is noisy, not that it is prevented, and it fails for three reasons. 1. The attacker needs one bit of feedback. A distinguishable error, a different response time, a retry, a log entry, a downstream side effect — any of these makes the service an oracle, and oracles turn tamper-only access into full plaintext recovery. 2. Many plaintexts tolerate corruption: bitmaps, fixed-offset records, bitmask flags, media containers, and anything where the field you care about is far from the field that got garbled. 3. The attacker gets unlimited attempts unless something rate-limits them. ## Authenticated encryption An **AEAD** scheme has the interface `encrypt(key, nonce, plaintext, associated_data) -> ciphertext+tag` and `decrypt(key, nonce, ciphertext+tag, associated_data) -> plaintext OR FAIL`. It provides IND-CPA **plus integrity of ciphertexts (INT-CTXT)**: an adversary cannot produce any ciphertext the sender did not produce that decrypts successfully. The standard result is that IND-CPA together with INT-CTXT gives security against chosen-ciphertext attack — which is exactly the class the oracles above live in. The all-or-nothing part of the contract is load-bearing. If an implementation releases plaintext bytes before verifying the tag — streaming decryption of a large object, for instance — it has reintroduced the malleability it paid to remove. **Associated data** is the second half of the interface: bytes that are *not* encrypted but *are* covered by the tag. Version number, key identifier, nonce, record id, tenant id, file path. This is how a ciphertext gets bound to its context, so a valid record cannot be lifted from one row, tenant or file and pasted into another. ## Authenticity is not a signature A symmetric tag proves the ciphertext was produced by *someone holding the key*. Both parties hold it, so there is no non-repudiation and nothing a third party can adjudicate — that asymmetry belongs to digital signatures, not to modes. ## Confidentiality, integrity, authenticity, freshness An AEAD gives the first three, within the scope of one key. It gives **no freshness**. A complete, valid ciphertext replayed later is still valid; an old record restored from a backup verifies perfectly. Freshness requires a sequence number, timestamp, or session-bound value carried in the associated data and *checked* by the receiver. ## The ladder Structural separation (pick a standard authenticated mode; the composition is not yours to invent) beats escaping/transformation-style fixes (hand-building an encrypt-then-MAC composition — correct in principle, but now you own the ordering, the tag comparison and exactly which bytes are covered), which beats validation (plaintext sanity checks after decryption — heuristic), which beats detection (alerting on decryption failures). Each rung down trades a guarantee for a heuristic.