Frontend Labs
⋯

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

  1. What is AES's block size, and does it change with key size?
  2. Name the four operations in an AES round (roughly).
  3. Why might ChaCha20 be preferable to AES on a phone?
  4. 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".

Generated from real-life-guide.md · 8 Oct 2026 16:36