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 read

Intuition

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.

Mechanism

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.

Mechanism

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 figure itself did not survive PDF extraction, so it is not reproduced here, but the mechanism behind it is exactly the formula above: $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.

Threat

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.

Control

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.

Mechanism

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 encrypt

C_i = E_k(P_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

Formula

CBC decrypt

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

$D_k$: the block cipher's decryption function under key k
$C_i, C_{i-1}$: the current and previous ciphertext blocks

Mechanism

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.

Threat

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.

Control

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.

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.

Mechanism

The slides name two further modes, Cipher Feedback (CFB) and Output Feedback (OFB), grouped with CTR under “Other Block Modes,” but the extracted slide text carries only the three names next to diagram placeholders; the actual construction did not survive PDF extraction, in the cleaned notes or in the raw text dump. Both turn the block cipher into a stream cipher by using only its encrypt direction, even to decrypt. The standard construction, from the same Stallings textbook both the notes and slides cite for this section, is:

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.

Mechanism

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.

Mechanism

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.

Threat

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.

Control

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.

Mechanism

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.

Worked example

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.

Aside

This is worked through in the abstract, with $\Delta$ standing for one flipped bit and made-up illustrative bytes for the block- $i{+}1$ check, deliberately not with Tutorial 4’s own ciphertext. Tutorial 4’s solutions have not been released, and its specific scenario is for the reader to work through directly, using the mechanism established above.

Mechanism

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)

Compare

Sequential: block $i$ needs block $i-1$ ‘s ciphertext before it can be encrypted, so CBC cannot be parallelised. A flipped ciphertext bit garbles the block it is in, and flips exactly one bit of the next block; blocks after that decrypt correctly.

Independent: block $i$ ‘s keystream depends only on the nonce and $i$ , so every block can be encrypted or decrypted in parallel. A flipped ciphertext bit changes exactly that one bit of that one block’s plaintext, and nothing else. There is no next-block effect at all.

Exam detail

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.

Source

Week 4 notes PDF