Modes of operation

How ECB, CBC, CFB, OFB and CTR turn one block cipher into something that can encrypt a whole message, and what breaks when a mode's IV or nonce requirement is ignored.

Explain why a block cipher needs a mode of operation before it can encrypt more than one block.
State ECB's pattern-leakage failure and why it is not used in practice.
State CBC's IV requirement and explain how WEP's 24-bit IV broke it in practice.
Describe CFB, OFB and CTR, and state which of the five modes can be parallelised.
Trace what one flipped ciphertext bit does to CBC decryption, block by block.

20 min readJump to the quiz ↓

ECB leaks repeated blocks even when the cipher is sound

A block cipher only defines how to scramble one fixed-size block: 64 bits for DES, 128 for AES. Every real message is longer than that. A mode of operation is the rule for using that one-block operation, over and over, to encrypt a message of arbitrary length. The obvious rule, encrypt every block the same way, is not automatically safe: a deterministic function given the same input twice always produces the same output twice.

Electronic Codebook (ECB) is that obvious rule. Each plaintext block is encrypted independently, with no connection between blocks at all:

Formula

ECB

C_i = E_k(P_i)

$P_i$: plaintext block i
$C_i$: ciphertext block i
$E_k$: the block cipher's encryption function under key k

Electronic Codebook (ECB) — each block encrypted independently

ECB has no chaining and no IV: identical plaintext blocks always produce identical ciphertext blocks, which is why it leaks patterns (a plaintext image's outline survives encryption) and is not used in practice.

Because $E_k$ is deterministic, two identical plaintext blocks under the same key always produce two identical ciphertext blocks. Real plaintext has repeating structure constantly: a run of the same byte in a file, or a large flat-coloured region of an image, generates the same plaintext block over and over, and ECB maps every one of those repeats to the same ciphertext block. The notes’ own illustration of this, an image encrypted block by block under ECB (Figure 15, “ECB Encryption Example”), shows exactly that failure: the image’s large repeated regions still show up as visibly repeated ciphertext, so the outline of the original picture survives “encryption” even though no individual pixel value can be read off directly. The formula expresses this directly: $P_i = P_j \Rightarrow C_i = C_j$ , for any two blocks encrypted under the same key.

ECB has no IV and no chaining, which is also why it is trivially parallelisable, and why, beyond teaching this exact problem, it is not used.

Under ECB, identical plaintext blocks always encrypt to identical ciphertext blocks under the same key. An attacker who never recovers the key can still read the plaintext’s block-level structure directly off the ciphertext, which blocks repeat, where, and how often, enough to recover an image’s outline or a file’s large-scale layout without decrypting a single block.

Make every block’s input differ even when two plaintext blocks are identical, by combining each block with something that changes: the previous ciphertext block, an encrypted counter, or a keystream built the same way. Every mode on the rest of this page exists specifically to close this gap.

CBC chains blocks and needs a fresh IV

Cipher Block Chaining (CBC) is the direct fix. Each plaintext block is XORed with the previous ciphertext block before encryption, so the input to $E_k$ changes even when two plaintext blocks are identical:

Formula

CBC encryption and decryption

C_i = E_k(P_i \oplus C_{i-1}), \qquad P_i = D_k(C_i) \oplus C_{i-1}

$P_i, C_i$: plaintext and ciphertext block i
$C_{i-1}$: the previous ciphertext block, or the IV when i = 0
$E_k, D_k$: the block cipher's encryption and decryption functions under key k

The first block has no previous ciphertext to chain from, so it is XORed with an initialization vector (IV) instead: a value generated fresh for each message and used in place of $C_{-1}$ . The IV does not need to be kept secret. It is usually sent alongside the ciphertext, because decryption needs it to reconstruct $P_0$ : what protects the scheme is not the IV’s secrecy but its uniqueness.

Cipher Block Chaining (CBC) — each block XORed with the previous ciphertext

Each plaintext block is XORed with the previous ciphertext block before encryption; the first block is XORed with an IV instead. The IV need not be secret, but must never repeat under the same key, or identical plaintext prefixes produce identical ciphertext again.

Reusing an IV under the same key regenerates the exact same $P_0 \oplus \text{IV}$ input for any two messages that start with the same plaintext block, so those two messages encrypt to the same first ciphertext block, the identical-plaintext-identical-ciphertext failure ECB has, reappearing at the message level instead of the block level.

Never reuse an IV under the same key. Generate a fresh IV, random or otherwise guaranteed not to repeat, for every message encrypted under that key. The IV’s job is to make each message’s encryption path unique, not to hide anything.

CFB and OFB feed back different values

The slides name Cipher Feedback (CFB) and Output Feedback (OFB). The constructions below are supplementary, from the Stallings textbook cited by the lecture. Both turn a block cipher into a stream cipher using only its encrypt direction, even to decrypt:

CFB: $O_i = E_k(C_{i-1})$ , then $C_i = P_i \oplus O_i$ , with $C_{-1}$ replaced by the IV. Each block’s keystream is built by encrypting the previous ciphertext block.

OFB: $O_i = E_k(O_{i-1})$ , then $C_i = P_i \oplus O_i$ , with $O_{-1}$ replaced by the IV. Each block’s keystream is built by encrypting the previous keystream output, never the ciphertext.

The difference shows up in how a corrupted ciphertext block behaves on decryption. In CFB, a bit error in $C_i$ changes $P_i$ by exactly that bit, since $P_i$ XORs straight against a keystream. The tampered $C_i$ then feeds into $O_{i+1} = E_k(C_i)$ , so block $i+1$ ‘s keystream comes out unrelated to the honest one and $P_{i+1}$ is garbled completely. In OFB, the keystream never depends on the ciphertext at all, so a bit error in $C_i$ changes only $P_i$ ‘s matching bit and affects nothing else.

CTR encrypts independent counter values

Counter (CTR) mode solves a different problem. CBC’s chaining is inherently sequential: block $i$ needs block $i-1$ ‘s ciphertext before it can be encrypted, so CBC cannot be parallelised. CTR builds a keystream instead of chaining ciphertext: a nonce is combined with a counter that increments once per block, and that combination is encrypted to produce each block’s keystream, then XORed with the plaintext.

Formula

CTR keystream

C_i = P_i \oplus E_k(\text{nonce} \Vert i)

$i$: the per-block counter value, incremented once per block
$\text{nonce}$: a value combined with the counter, never reused under the same key
$E_k(\text{nonce}\Vert i)$: the keystream block for position i

Every block's keystream depends only on the nonce and its own counter value, never on another block's ciphertext.

Counter (CTR) — a keystream from the nonce and counter, XORed with plaintext

A nonce concatenated with a per-block counter is encrypted to build a keystream, which is then XORed with the plaintext — encryption becomes a stream cipher built from a block cipher. Blocks no longer depend on each other, so CTR parallelises where CBC cannot.

Because block $i$ ‘s keystream depends only on the nonce and $i$ itself, not on any other block’s ciphertext, every block’s keystream can be computed independently, and in parallel, unlike CBC. The nonce plays the same role the IV plays elsewhere: it does not need to be secret, but reusing it under the same key is fatal.

Reusing a nonce (with the same counter value) under the same key regenerates the exact same keystream block for that position. If an attacker XORs the two resulting ciphertexts together, the keystream cancels out entirely, leaving the XOR of the two plaintexts, and from there, known- or guessable-plaintext techniques recover both messages.

Never reuse a nonce-and-counter pair under a given key. In practice: draw a fresh nonce per message, whether random or a counter that is never reset while the key stays the same, and never re-encrypt under a nonce that has already been used with that key.

Recall

ECB, CBC and CTR are all built from the same underlying block cipher. Why does only CTR let every block be encrypted in parallel, without also having ECB's pattern-leakage problem?

CTR’s keystream for block i, $E_k(\text{nonce} \Vert i)$ , depends only on the nonce and that block’s own counter value: nothing from any other block, and nothing that repeats across identical plaintext blocks either, since the counter changes every time. ECB is also parallelisable, but only because it has no chaining at all, which is exactly what makes it leak patterns. CBC’s input to block i is $P_i \oplus C_{i-1}$ , so block i cannot be encrypted until block i-1’s ciphertext exists, forcing it to run in sequence.

Chaining determines how ciphertext errors spread

Tutorial 4 asks what happens when one byte of a CBC ciphertext is corrupted before decryption. The chaining structure above makes the answer fall out algebraically, one block at a time.

Try it — worked example

In CBC mode, one bit of ciphertext block C_i is flipped before decryption. What happens to plaintext blocks i, i+1, and i+2 onward?

Show answer and steps

AnswerBlock i's plaintext comes out unrelated to the original; block i+1's plaintext differs by exactly the flipped bit; every block from i+2 onward decrypts correctly.

Start from the honest decryption of two consecutive blocks: $P_i = D_k(C_i) \oplus C_{i-1}$ and $P_{i+1} = D_k(C_{i+1}) \oplus C_i$ .
An attacker flips one bit of ciphertext block $i$ only. Call the flipped bit $\Delta$ , an 8-bit string with a single 1, for example $\Delta = 00001000$ for bit 3. The tampered block is $C_i' = C_i \oplus \Delta$ . Every other ciphertext block, including $C_{i-1}$ and $C_{i+1}$ , is untouched.
Block $i$ . Decryption now computes $P_i' = D_k(C_i') \oplus C_{i-1} = D_k(C_i \oplus \Delta) \oplus C_{i-1}$ . $D_k$ is the full block cipher’s decryption function, not a bitwise operation: every block cipher is built so that changing one input bit changes roughly half the output bits, unpredictably (the avalanche property). $D_k(C_i \oplus \Delta)$ bears no simple relationship to $D_k(C_i)$ , so $P_i'$ comes out unrelated to the true $P_i$ : block $i$ is garbled.
Block $i+1$ . Decryption computes $P_{i+1}' = D_k(C_{i+1}) \oplus C_i'$ . $C_{i+1}$ itself was never touched, so $D_k(C_{i+1})$ is exactly what it was before the tamper. Call that value $K$ . By definition $P_{i+1} = K \oplus C_i$ , so $K = P_{i+1} \oplus C_i$ .
Substitute $C_i' = C_i \oplus \Delta$ and the expression for $K$ : $P_{i+1}' = K \oplus C_i' = (P_{i+1} \oplus C_i) \oplus (C_i \oplus \Delta) = P_{i+1} \oplus (C_i \oplus C_i) \oplus \Delta = P_{i+1} \oplus \Delta$ . The two $C_i$ terms cancel, since $x \oplus x = 0$ , leaving exactly the flipped bit.
A concrete check with illustrative bytes, not tied to any specific message: let $C_i = 10110100$ . Flipping bit 3 gives $\Delta = 00001000$ and $C_i' = 10110100 \oplus 00001000 = 10111100$ . Let $P_{i+1} = 01100101$ , so $K = P_{i+1} \oplus C_i = 01100101 \oplus 10110100 = 11010001$ . Then $P_{i+1}' = K \oplus C_i' = 11010001 \oplus 10111100 = 01101101$ . Directly, $P_{i+1} \oplus \Delta = 01100101 \oplus 00001000 = 01101101$ , the same value both ways, confirming block $i+1$ differs from the honest plaintext in exactly bit 3 and nowhere else.
Block $i+2$ and beyond. $P_{i+2} = D_k(C_{i+2}) \oplus C_{i+1}$ uses only $C_{i+1}$ and $C_{i+2}$ , neither of which the tamper touched. Every block from $i+2$ onward decrypts exactly as if nothing had happened.

Try it directly: set the mode to CBC below, encrypt a few blocks, then flip one bit of one ciphertext block and decrypt. The trace shows exactly this pattern: one block garbled, the next block off by one bit, everything after untouched. Switching the mode to ECB or CTR and repeating the same tamper shows the contrast Tutorial 4 is really asking about: ECB confines the damage to the one tampered block and nothing else, while CTR flips exactly the targeted bit in that one block only, with no effect on any other block.

Trace ECB, CBC, CFB, OFB and CTR block by block, then flip one ciphertext bit and see which plaintext blocks it corrupts.

Mode

key (0–255)

IV (0–255)

Plaintext blocks (space-separated, 0–255 each)

Teaching model — an 8-bit toy cipher, not real encryption. The mode is what is under test here, not the cipher.

Block	Plaintext	Input	Output	Ciphertext	Chain in

Tamper: flip one ciphertext bit, then decrypt

Block index

Bit index (0–7)

Exam detail

Wired Equivalent Privacy (WEP) is the lecture’s worked case of an IV-reuse failure in the wild. WEP encrypted wireless traffic with RC4, a stream cipher, by combining a secret key with a 24-bit IV. The same uniqueness requirement applies to a stream cipher’s IV as to CBC’s. $2^{24}$ is small enough that on a busy network, IVs start repeating quickly. Once an attacker captures two packets encrypted under the same IV and key, RC4 produces the same keystream both times. Where the attacker knows or can guess part of one plaintext, such as a protocol header, they can strip the keystream off directly and start recovering the other plaintext; enough repeated-IV captures let them work back to the secret key itself.

The full picture, across all five modes, on the four properties the exam actually asks about:

Mode	Parallelisable	One flipped ciphertext bit	Needs	Leaks patterns
ECB	Yes, no chaining at all	Garbles that one block entirely; nothing else affected	Nothing	Yes
CBC	No, sequential chain	Garbles the tampered block; flips exactly one bit of the next block	An IV, never reused	No
CFB	No, sequential chain	Flips exactly one bit of that block; garbles the next block entirely	An IV, never reused	No
OFB	No, keystream generation is sequential	Flips exactly one bit of that block; no effect on later blocks	An IV, never reused	No
CTR	Yes, every block’s keystream is independent	Flips exactly one bit of that block; no effect on any other block	A nonce, never reused	No

Every row after ECB pays for its safety with something ECB does not need: an IV or nonce that must never repeat under the same key. That trade is what “distinguish between the modes” is really testing, not which one is fastest, but which properties each buys and at what cost.

Pitfall

Do not write that CBC “can’t be parallelised” as though this were unique to it among the chained modes. CFB shares it, since each block’s keystream is built by encrypting the previous ciphertext block. Only ECB (because it has no chaining) and CTR (because each block’s keystream depends only on its own counter) can run every block at once. ECB pays for that with the pattern-leakage failure this page opens with.

Check yourself

Source

Week 4 slides PDF