State the contract an initialization vector or nonce must satisfy in CBC-style and counter-style encryption modes, and describe exactly what an attacker gains when the same nonce is reused under the same key.

## What the value is for An initialization vector or nonce exists to destroy determinism: it makes the same plaintext under the same key encrypt to unrelated ciphertexts. It is transmitted or stored **in the clear** alongside the ciphertext — it is not a secret and not a second key. Its entire security contribution is a *repetition* property, and the exact property required differs by mode. Getting that difference wrong is one of the most common real cryptographic failures in application code. ## CBC: unique *and* unpredictable In CBC each plaintext block is XORed with the previous ciphertext block before encryption; for the first block, the IV plays that role. Uniqueness alone is not sufficient here — the IV must also be **unpredictable to the attacker before they choose their plaintext**. The reason is an adaptive chosen-plaintext guess-confirmation attack. Suppose an attacker can (a) cause a message to be encrypted that contains both attacker-chosen data and an unknown secret, (b) observe the ciphertext, and (c) predict the IV that will be used next. They can then craft a block that, once XORed with the predicted IV, equals their *guess* for the secret block XORed with the corresponding earlier ciphertext block. If the resulting ciphertext block matches the earlier one, the guess was right. Aligning the message so that only one unknown byte falls in the block reduces this to at most 256 guesses per byte. This is the mechanism behind the well-known attacks on protocols that used the previous record's last ciphertext block as the next record's IV — a scheme that is unique but perfectly predictable. So: for CBC, generate the IV from a cryptographically secure random source, full block length, per message. ## Counter-style modes: uniqueness, absolutely Counter-style modes derive a keystream by encrypting successive counter blocks built from the nonce, and XOR that keystream with the plaintext. Predictability is irrelevant — the nonce may be a simple increasing integer. What matters is that **a (key, nonce) pair is never used twice**. If it is, the same keystream is produced twice. Then `C1 XOR C2 = (P1 XOR KS) XOR (P2 XOR KS) = P1 XOR P2` The key has vanished from the equation. The attacker now has the XOR of two plaintexts, and because real plaintexts are highly structured (headers, formats, natural language, known field layouts), that is routinely enough to separate them; if any part of one plaintext is known or guessable, the corresponding part of the other falls out directly. Worse, the attacker can now *forge*: knowing the keystream for those positions lets them encrypt anything of their choosing under that nonce. ## Why reuse in a Galois-tag mode is a different order of disaster Authenticated counter modes that compute their tag with a polynomial MAC in a binary field derive an authentication subkey from the block cipher and evaluate a polynomial over the ciphertext blocks at that subkey. Given two messages authenticated under the **same nonce and key**, the difference of the two tag equations becomes a polynomial equation in one unknown — the subkey — with a small number of roots. The attacker solves it. The consequence is not "those two messages are compromised." It is that the attacker can now compute a valid tag for **any ciphertext of their choosing** under that key, indefinitely. Confidentiality loss is per-message; this authentication loss is permanent for the key. This is why nonce reuse in such modes is treated as an incident that requires key rotation, not merely re-encryption of the affected records. ## Two generation strategies, and how each fails **Random nonces.** Simple and stateless, but subject to the birthday bound: with a 96-bit nonce, collisions become non-negligible as message counts approach 2^48, and a conservative deployment budget keeps per-key message counts far below that — commonly quoted at around 2^32 messages per key for a very small collision probability. Random nonces are the right default when you cannot guarantee single-writer state. They also require a genuinely cryptographic random source, which is a separate discipline of its own. **Deterministic counters.** Zero collision risk *if* the counter is truly monotonic and owned by exactly one writer. The failure modes are all operational: two instances of a service both start at zero; a container is restored from a snapshot and replays counter values; a virtual machine is cloned; a crash loses the last persisted value and the process resumes from an older number; a "stateless" function is scaled horizontally. A common safe pattern is to partition the nonce space — a per-instance or per-key-epoch prefix plus a local counter — so that no two writers can ever produce the same value. **Per-key message budgets.** Both strategies imply a limit on how many messages a single key may protect. Key rotation is therefore not just a hygiene practice; it is what keeps you inside the nonce space. Deriving a fresh data key per record or per session from a long-lived key bounds the problem structurally: each derived key sees so few messages that the nonce question nearly disappears. **Misuse-resistant constructions.** Some authenticated modes are designed so that nonce reuse degrades gracefully: repeating a nonce leaks only whether two messages were identical, and never the authentication key. The cost is that they must process the plaintext twice, so they do not stream. When you cannot guarantee nonce discipline — many uncoordinated writers, unreliable state — this is the structural answer rather than a procedural one. ## The ladder applied here Structural separation: choose a construction where the nonce cannot repeat by design (per-message derived keys, partitioned nonce space, or a misuse-resistant mode). Below that, transformation-style care: a correctly seeded random nonce of full width. Below that, validation: asserting in code that a nonce has not been seen. At the bottom, detection: monitoring for duplicate nonces after the fact — which tells you that you must rotate the key, and nothing more.