Modes of operation
A block cipher such as AES does one thing: with a key, it turns exactly 16 bytes into 16 other bytes, and back. A message is almost never exactly 16 bytes. A mode of operation is the rule for using the block cipher on a whole message, and it turns out to matter as much as the cipher itself: with the wrong mode, a perfect cipher leaks the shape of a picture, and lets an attacker rearrange a payment without knowing the key.
Every figure here uses real AES, the same code the block ciphers page steps through, checked against the published test vectors for each mode.
1 · One block at a time: ECB
Section titled “1 · One block at a time: ECB”The obvious way: cut the message into 16-byte blocks and encrypt each one on its own, with the same key. It’s called electronic codebook mode, ECB, because it works like a codebook: each possible block has its own fixed code.
The last block is usually short, so it’s filled out first, with padding that can be removed again. The usual rule (PKCS#7) adds n bytes, each of value n: three bytes short means three bytes of 03. A message that’s already a whole number of blocks gets a whole block of 16s, so that the receiver can always strip the last byte’s worth without wondering whether it’s padding.
A message cut into 16-byte blocks, each encrypted with AES under one random key. Ciphertext blocks that are equal get the same colour. The padding is shown as its bytes, in hex. The breakfast order has two identical blocks, and in ECB they encrypt identically: an eavesdropper can’t read either, but can see they’re the same. Type your own message. The last tile encrypts the same message with your browser’s own built-in AES, as a check on this page’s. (Leave the other modes for now: sections 3 and 4.)
Equal blocks giving equal ciphertext is easy to shrug off in text. It’s much harder to shrug off in a picture.
A picture of 240 × 160 pixels, each pixel 4 bytes (red, green, blue and opacity), so each 16-byte block is four pixels side by side. Encrypted with AES in ECB, every block of four pixels of the same flat colour becomes the same four random-looking pixels, and the picture’s shapes show straight through. Try your own picture: it’s processed in your browser and never leaves it. Photos have few areas of exactly one colour, so simplify its colours first, or the leak only shows in the flat parts.
The cipher isn’t broken: no single block can be read. But the pattern of blocks is the plaintext’s pattern, and that’s plenty. In the guessing game on What we want from cryptography, an attacker who picks two messages, one with a repeated block and one without, wins every round against ECB.
2 · Cut and paste
Section titled “2 · Cut and paste”ECB has a second weakness: every block stands alone, so blocks can be moved, repeated or swapped, and each still decrypts perfectly.
Suppose a bank’s system encrypts every payment request with the same key, in a fixed layout of three blocks: which account it’s from, which account it’s to, and how much. Bob is paying Alice back for dinner. Mallory is a customer of the bank too, and has sent a request of their own, so has its ciphertext and knows exactly what each block says.
Bob’s request, Mallory’s own request, and what the bank receives: choose which ciphertext block goes in each of the three places. Pay Mallory sends Bob’s first block (who’s paying) with Mallory’s second and third (where to, and how much). Under ECB the bank decrypts a perfectly formed request: from Bob’s account, to Mallory’s, for $900. Mallory never needed the key, or even to read Bob’s request. Switch to CBC (next section) and try again: the pasted blocks come out as rubbish.
So ECB leaks patterns and lets blocks be rearranged. It’s fine for encrypting a single block, which is how the other modes use AES, and for nothing else.
3 · Chaining: CBC
Section titled “3 · Chaining: CBC”The fix for repeats is to make each block’s encryption depend on what came before. Cipher block chaining (CBC) XORs each plaintext block with the previous ciphertext block, then encrypts the result. The first block has no previous block, so it’s XORed with an initialisation vector (IV): 16 random bytes, chosen afresh for every message and sent in the clear in front of it.
CBC encryption. Each ciphertext block is fed into the next block’s XOR (the coloured lines), so every block depends on all the blocks before it, and on the IV.
The random IV does two jobs. Two equal blocks in one message now encrypt differently, because they’re XORed with different ciphertext first. And the same whole message, sent twice, encrypts differently each time, which the guessing game requires.
The same picture in CBC: the shapes are gone, and every block of the encryption is different. Switch between ECB and CBC to compare, or try CTR, from the next section.
To decrypt, the receiver decrypts each block and XORs the result with the ciphertext block before it. That gives Mallory a lever. Flip a bit in one ciphertext block, and two plaintext blocks change: that block decrypts to rubbish, and the same bit flips in the next block, exactly, because the ciphertext was XORed straight into it. It’s the bit-flipping from What we want from cryptography, one block along.
Bob’s request in CBC. Mallory, knowing the layout and Alice’s account number, XORs (4821 ⊕ Mallory’s account) into the four bytes of ciphertext block 1 that sit above the account number in block 2. The bank decrypts block 2 with Mallory’s account number in it, and block 1 as rubbish (changed bytes in orange). Or Mallory can change the FROM account through the IV instead: the IV is only ever XORed, never decrypted, so nothing at all is garbled.
A garbled block might be noticed, or it might not: plenty of software never checks a field it doesn’t use. And through the IV, the first block can be changed with no sign at all. CBC hides patterns; it still doesn’t protect the message.
4 · A counter: CTR
Section titled “4 · A counter: CTR”Counter mode (CTR) uses AES differently: not on the message at all. It encrypts a counter, a nonce (a number used once, chosen for each message) followed by 1, 2, 3 and so on, and XORs the results with the message. AES becomes a generator of keystream, and the mode becomes a stream cipher.
CTR encryption. AES encrypts the nonce and a block number; the result, the keystream, is XORed with the plaintext. Decrypting is the same: make the same keystream, and XOR again.
That has some handy consequences. There’s no padding: the last block’s keystream is simply cut short. Each block’s keystream depends only on its number, so blocks can be encrypted and decrypted in any order, or all at once on many processors, and a receiver can decrypt block 1,000 without touching the 999 before it. Only AES’s encryption is ever used, never its decryption. (Choose CTR in the figures above: no padding, and no repeated blocks.)
The price is the same as the one-time pad’s: the keystream must never be used twice. With the same key and the same nonce, two messages get exactly the same keystream, and XORing the two ciphertexts cancels it.
Two pictures encrypted in CTR with the same key. With the same nonce for both, each ciphertext on its own looks like noise, but XORing the two cancels the keystream and leaves the two pictures XORed together: both show through. With different nonces, the XOR is noise too.
And like every XOR cipher, CTR lets Mallory flip any bit of the plaintext by flipping the same bit of the ciphertext, with no garbling anywhere.
5 · What none of them gives
Section titled “5 · What none of them gives”| ECB | CBC | CTR | |
|---|---|---|---|
| Equal plaintext blocks give equal ciphertext | always | no | no |
| Needs padding | yes | yes | no |
| Blocks encrypted in parallel | yes | no (each needs the one before) | yes |
| Blocks decrypted in parallel | yes | yes | yes |
| If an IV or nonce repeats | (there isn’t one: it always leaks) | messages that start the same encrypt the same, up to the first difference | the pad is reused: the two messages’ XOR leaks |
| Mallory can change the message | by moving blocks | by flipping bits (garbling the block before) | by flipping bits, cleanly |
The first four modes, ECB and CBC among them, were standardised in 1980, for DES; CTR was added in 2001. None of them was designed to stop a message being changed, and none does: a mode on its own gives confidentiality, and nothing else.
So what’s used in practice adds a check. Authenticated encryption combines a mode with a check value that only the key’s holders can compute, sent with the message; a receiver who finds the check doesn’t match throws the message away without decrypting it. The commonest is AES-GCM: CTR for the secrecy, plus a check computed over the ciphertext. TLS 1.3, which secures most web traffic, allows only authenticated encryption.
Summary
Section titled “Summary”- A block cipher encrypts one block; a mode of operation says how to encrypt a whole message.
- ECB encrypts each block alone: equal blocks give equal ciphertext (the picture shows through), and blocks can be cut and pasted.
- CBC XORs each block with the previous ciphertext (a random IV for the first): patterns vanish, but a flipped bit flips the same bit one block on.
- CTR encrypts a counter to make a keystream: no padding, fully parallel, but a repeated nonce is a reused pad.
- None of them stops changes: real systems use authenticated encryption such as AES-GCM.
Further reading
Section titled “Further reading”- Morris Dworkin, Recommendation for Block Cipher Modes of Operation, NIST SP 800-38A (2001): the modes, and the test vectors this page is checked against.
- Jean-Philippe Aumasson, Serious Cryptography (2017): its chapter on block ciphers covers the modes and how they fail.
- The Cryptopals challenges (cryptopals.com), sets 1 to 3: detecting ECB, ECB cut-and-paste, CBC bit-flipping and fixed-nonce CTR, to break in code yourself.