ECB, CBC, and CBC padding arithmetic

ECB: a codebook, and why that is bad

Electronic Codebook (ECB) mode is the simplest possible way to use a block cipher on a long message: split the plaintext into blocks and encrypt each one independently under the same key, $C_i=E(K,P_i)$. The name comes from the mental model — for a fixed key there is a unique ciphertext for every possible plaintext block, exactly as if you owned a gigantic codebook mapping one to the other.

The fatal property is right there in the definition: identical plaintext blocks always produce identical ciphertext blocks. For a structured message — a form with repeated fields, an image with flat colour regions, a database record format — the repetition in the plaintext shows straight through as repetition in the ciphertext, even though not one byte of the actual content has been read. And there is a second failure that is easy to miss: because each block is independent, an attacker who cannot read a single byte can still substitute, delete or reorder ciphertext blocks, and every block still decrypts correctly under the unmodified key — only the meaning changes. That is the cleanest argument in the whole course for why encryption is not authentication: ECB gives you confidentiality of content and gives you nothing at all about integrity of order. ECB's legitimate use is narrow — transmitting a single value, such as one encryption key, where there is no second block to compare it against.

CBC: chaining breaks the pattern

Cipher Block Chaining (CBC) fixes exactly this by making each block's ciphertext depend on every block before it. An initialization vector (IV) starts the chain:

$$C_1=E(K,P_1\oplus \text{IV}),C_j=E(K,P_j\oplus C_{j-1})$$

Decryption reverses it block by block:

$$P_1=D(K,C_1)\oplus \text{IV},P_j=D(K,C_j)\oplus C_{j-1}$$

Two identical plaintext blocks now produce different ciphertext, because each is XORed with a different predecessor before encryption. The pattern that gave ECB away is gone.

Worked example. Encrypt the four-block message HOLD | 0500 | HOLD | 0500 — two repeated blocks — first under ECB and then under CBC with the same key and a fixed IV, using a small four-byte toy cipher $E(K,x)={\mathrm{rotl}}_{11}((x\oplus K)\cdot m\mathrm{mod}{2}^{32})$ for a fixed odd multiplier $m$:

ECB:  cd7bcf9f 65f96e38 cd7bcf9f 65f96e38     <- blocks 1 and 3 identical; 2 and 4 identical
CBC:  0c1b3fbe aca498a5 78996569 e018a67e     <- no repeats at all

Under ECB, the repetition of HOLD and 0500 is plainly visible in the ciphertext. Under CBC it has vanished completely, because block 3's input is XORed against block 2's ciphertext, and block 2's ciphertext already looks nothing like block 4's.

What the IV actually protects

Here is the argument that is worth more than any other sentence in this lesson: the IV must be protected as well as the key is — not merely known, but not attacker-controlled. From the first decryption equation, $P_1=\text{IV}\oplus D(K,C_1)$. Complementing bit $i$ of the IV complements bit $i$ of the recovered $P_1$ — nothing else about the message changes. An attacker who can flip IV bits in transit can flip chosen bits of the first block only of the recovered plaintext without ever touching the key, which is three lines of algebra proving that confidentiality is not integrity. This is also the strongest available answer to "why does a real protocol like TLS need a MAC as well as a cipher": CBC alone gives no way to detect that the IV, or any ciphertext block, was tampered with in transit.

An IV therefore does not need to be secret — many protocols transmit it in the clear — but it does need to be unpredictable and non-malleable: unpredictable so an attacker cannot precompute useful ciphertexts, and non-malleable so flipping IV bits is either impossible or detected. "The IV is public, so it must be safe to reuse or leave unauthenticated" is exactly the wrong inference.

CBC padding — CBC-Pad

CBC needs a whole number of blocks, and a real message's length is almost never a multiple of the block size. CBC-Pad always adds between 1 and $bb$ bytes, where $bb$ is the block size in bytes, and — this is the detail worth its own paragraph — every pad byte carries the value of the pad length. Pad with three bytes and each of those three bytes has the value 03; pad with one byte and it has the value 01. The receiver strips exactly as many trailing bytes as the value of the last byte says to strip.

Worked arithmetic. Take a plaintext of 742 bytes and a block size of 20 bytes. The block size is deliberately not 16 here: the method has to survive whatever size the question hands you, and a learner who has only ever divided by 16 tends to reach for it by reflex.

$$742=37\times 20+2$$

Thirty-seven full blocks account for 740 bytes, leaving a 2-byte remainder. The pad must bring that remainder up to a full 20-byte block, so the pad is $20-2=18$ bytes, each with value 12 hexadecimal (18 decimal). Total ciphertext length: $742+18=760$ bytes, which is $760/20=38$ blocks.

The three steps are always the same, whatever the numbers: divide to get the remainder, take block size minus remainder as the pad (never the remainder itself), then divide the padded total by the block size for the block count.

And now the half where the marks actually get lost. If the plaintext is already an exact multiple of the block size, is padding still needed? Yes — a full extra block of padding is added. If no padding were added on an exact multiple, the receiver would have no way to distinguish "this message ends exactly on a block boundary" from "this message ends with some data that happens to look like a valid pad": the pad-length convention only works if the last byte's value is always the pad length, and a message of zero padding bytes cannot encode "there were zero pad bytes" without breaking that rule (the minimum legal pad is one byte, of value 01). So an exact multiple gets a full block of padding, every byte of which has value $bb$.