Chapter 13 — Block ciphers and AES
In one sentence
AES scrambles data in fixed 128-bit blocks using a key, and it is the symmetric cipher you should use unless you have a specific reason not to.
Block vs stream ciphers
BLOCK CIPHER STREAM CIPHER
encrypts fixed-size chunks generates a keystream, XORs it
AES: always 128-bit (16-byte) blocks ChaCha20, and AES in CTR mode
needs PADDING if data isn't a works on any length, byte by byte
multiple of the block size
In practice the line is blurry: AES in counter mode (Chapter 14) is a stream cipher built from a block cipher.
AES, briefly
AES (Advanced Encryption Standard) was selected by NIST in 2001 after a five-year open competition. The winning design was called Rijndael.
Block size: 128 bits (16 bytes) -- ALWAYS, for every key size
Key sizes: 128, 192, or 256 bits
Rounds: 10 (AES-128), 12 (AES-192), 14 (AES-256)
Each round performs four steps on a 4×4 byte grid:
SubBytes substitute each byte via a lookup table (non-linearity)
ShiftRows shift row i left by i positions (diffusion across columns)
MixColumns mix the bytes within each column (diffusion within columns)
AddRoundKey XOR with a key derived for this round (the secret)
You never need to implement this. What matters is the properties: after 10+ rounds, every output bit depends on every input bit and every key bit, and no known attack does meaningfully better than brute force.
Optional detail: the best known attacks on full AES-256 reduce the work from 2^256 to about 2^254 — an academic result with no practical impact. Related-key attacks exist against AES-192/256 but require key relationships that don't occur in correct use.
AES-128 vs AES-256
| AES-128 | AES-256 | |
|---|---|---|
| Brute force | 2^128 — infeasible forever | 2^256 — infeasible forever |
| Speed | ~40% faster | slower (14 rounds vs 10) |
| Post-quantum (Grover) | ~2^64 effective — uncomfortable | ~2^128 effective — fine |
| Recommendation | Fine today | Use this for anything long-lived |
Chapter 23 explains the Grover column. Short version: use AES-256 — the cost is small and it is the simple hedge against quantum attacks on symmetric crypto.
Hardware acceleration matters enormously
Modern CPUs implement AES in hardware (Intel/AMD AES-NI, ARMv8 crypto extensions).
AES in software: ~100-200 MB/s per core
AES with AES-NI: ~1-5 GB/s per core -- 10-50x faster
This is why AES-GCM dominates TLS on servers. On hardware without acceleration (older ARM, some embedded, some phones), ChaCha20-Poly1305 is faster — which is exactly why TLS supports both and mobile clients often prefer ChaCha20.
Padding
A block cipher needs whole blocks. PKCS#7 padding appends N bytes, each with value N:
13 bytes of data + 3 bytes padding: ... 03 03 03
16 bytes of data (already a full block) adds a WHOLE extra block of 16 x 0x10
(so the receiver can always unambiguously remove padding)
Padding seems boring. It caused the padding oracle attack — one of the most important practical crypto attacks ever found (Chapter 14). Modes like CTR and GCM avoid padding entirely, which is one reason they won.
Practice (20 min)
cd ~/sec-lab/scratch
# --- Does your CPU accelerate AES? ---
openssl speed -evp aes-256-gcm 2>/dev/null | tail -4
openssl speed -evp chacha20-poly1305 2>/dev/null | tail -4
# On x86 check the flag directly:
grep -o aes /proc/cpuinfo 2>/dev/null | head -1 || sysctl -a 2>/dev/null | grep -i aes | head -2
# --- Block size is always 16 bytes ---
printf 'a' > one.txt
openssl enc -aes-256-ecb -K $(openssl rand -hex 32) -in one.txt -out one.enc
ls -l one.txt one.enc # 1 byte in, 16 bytes out -- padding
Break it: encrypt a 16-byte file and check the output size. Why is it 32 bytes and not 16? (Answer: padding must always be added so it can be unambiguously removed.)
Common confusions
- "AES-256 is twice as strong as AES-128." It's 2^128 times more work to brute force, but both are already infeasible. The real reason to prefer 256 is quantum hedging.
- "AES is broken because I read about an attack." Attacks on reduced-round AES and on bad implementations exist. Full AES with correct use is unbroken.
- "I should use the biggest key size for everything." Use AES-256, but know the real risks are mode misuse, key management, and side channels — not key size.
Check yourself
- What is AES's block size, and does it change with key size?
- Name the four operations in an AES round (roughly).
- Why might ChaCha20 be preferable to AES on a phone?
- Why does encrypting 16 bytes produce 32 bytes of output?
Further reading
- Standard: FIPS 197 — the AES specification. Surprisingly readable, with worked examples in the appendices.
- Interactive: "A Stick Figure Guide to AES" (moserware.com) — genuinely charming and accurate.
- Video: Computerphile, "AES Explained".