Interactive Demos
Fall 2026 · University of Illinois Urbana–Champaign
Fifteen browser demos for weeks 1–4 — perfect secrecy, pseudorandomness, semantic security, pseudorandom functions, block-cipher design and modes of operation (Katz & Lindell, chapters 2, 3 and 7). Each one runs entirely in your browser — nothing is installed, nothing is uploaded, and reloading the page starts over. Every control is keyboard reachable.
Perfect secrecy
Week 1 · KL chapter 2. Security against an adversary with unlimited time, and the price it costs in key length.
-
Estimating all four distributions from samples
Each trial draws a message x from the source and a key r uniformly, then forms the ciphertext c = x ⊕ r. The top row uses every trial; the bottom row keeps only the trials matching a chosen message or a chosen ciphertext, so those panels fill in far more slowly. Watch P(x | c) converge back onto P(x).
- P(x)
- P(c)
- P(c | x = x*)
- P(x | c = c*)
-
The indistinguishability experiment
You pick two messages. A hidden coin decides which one gets encrypted, and you see only the ciphertext. A scheme is perfectly indistinguishable when no strategy, on any pair of messages, beats a coin flip. Play the adversary yourself, or hand it to maximum likelihood and run a few hundred thousand rounds against a one-time pad, a short key, or biased key bits.
- The challenge
- Ciphertext under each coin
- Success rate over rounds
-
Build the reduction
Proposition 1 says a scheme is perfectly secret exactly when every message gives every ciphertext the same probability. Suppose that fails somewhere. Your job is to turn that single failure into an adversary that actually wins the distinguishing game — and to check that your construction never once looks at the key. This is the reduction from lecture, built one step at a time instead of read off a slide.
- Find where the proposition fails
- Turn it into a strategy
- Why it wins
- What you proved
-
Why the keys have to outnumber the messages
Every key turns the message list into a ciphertext list without collisions, otherwise decryption fails. Try to arrange the keys so that no ciphertext ever rules a message out. With fewer keys than messages the arrangement does not exist, and the grid shows you why — this is Shannon's bound, |K| ≥ |M|, built by hand.
- The scheme
- Keys sending m to c
- Posterior
- The counting argument
Pseudorandomness
Week 2 · KL chapter 3. Drop the unbounded adversary for an efficient one, and a short key starts to be enough.
-
Tell the machine from the coins
A pseudorandom generator is a function G : {0,1}n → {0,1}ℓ with ℓ > n: it stretches a short secret seed into a long stream. It is secure if no efficient test tells G(s) for a uniform seed apart from ℓ fair coin flips, better than guessing. You are that test — set the seed and stream lengths, then try to beat 50%. Shrink the seed and brute force starts beating you, which is the whole reason n has to be large.
- Parameters
- The machines
- Seed lab
- The exhaustive table
- Side by side
-
A pseudorandom generator is already an encryption scheme
Stretch a short key into a long pad, XOR it onto the message, and you have a cipher no eavesdropper can break — provided the generator is sound. Shannon says perfect secrecy needs a key as long as the message; give that up for computational secrecy and the key can be short. The proof is a reduction: any attacker on the cipher becomes, with a few lines of wrapping, a distinguisher for the generator.
- The scheme
- What security means here
- The reduction
-
One bit of stretch, and the hybrid argument that pays for the rest
A generator that adds a single bit looks useless. Iterate it and you get as many bits as you like — but the security proof no longer follows in one step, because the output now comes from many calls while the assumption speaks about one. The hybrid argument is how you cross that gap, and it charges you a factor of ℓ to do it.
- Why the proof is not one line
- The ladder of hybrids
- One link, one call
-
One challenge ciphertext, and the ladder that turns it into many
A scheme that hides one message under a key should hide a whole conversation under it, but the definition does not say so and the proof is not free. The adversary submits two vectors that may differ in every slot; the reduction you build receives exactly one challenge ciphertext, so the two worlds it can manufacture differ in exactly one. Hybrids are the chain of one-slot moves that joins the ends, and chosen-plaintext access is what makes each link buildable — which is why the same claim is false for eavesdropping security.
- Why one difference is not enough
- Build the reduction
- Walk the ladder
- Where ½ + δ/2 comes from
Semantic security and leakage
Week 3 · KL 3.2.2. What a security proof actually promises, and how to state precisely how much a scheme gives away.
-
What the simulator knows
A simulator is a forger that never sees the messages: hand it a short list of facts and let it invent the ciphertexts. One slider controls that list, from nothing at all up to the plaintext itself. The leftmost setting at which an observer stops beating a coin flip is exactly what the scheme leaks — the length alone for a randomized cipher, and, once you switch schemes, the length together with the pattern of repeated words for a deterministic one. Everything to the right of that point is information the encryption never revealed.
- What the simulator may know
- Two worlds, same messages
- The observer's advantage
- The implication
Pseudorandom functions
Week 3 · KL 3.5.1. Replace the random string of a PRG with a random function: a lookup table far too big to store, imitated by a short key and a public recipe.
-
PRF Oracle Room
A truly random function is a table with a fresh coin flip in every row; a pseudorandom function FK computes each row from a short key instead. First poke at both tables and watch weak recipes (x ⊕ K, x + K, K · x) give themselves away. Then try to predict a row you have not looked up — impossible for the random table and for a good PRF, easy for the broken ones. Finally play the distinguishing game from the definition, with the game's pseudocode highlighting each step and your advantage estimated live.
- Truly random function
- Pseudorandom function
- Predict the unseen row
- Tell them apart
Block ciphers
Week 3 · KL 7.2. How a practical block cipher is actually built: a nonlinear step and a mixing step, repeated, until the ciphertext hides both the key and the message.
-
Confusion and diffusion
Shannon's two design principles, made concrete on a 16-bit substitution–permutation network you can take apart. Inject a one-bit difference and watch it light up S-boxes round by round; switch the S-box off and the difference never grows, switch the permutation off and it never leaves its nibble. A key-dependency heatmap shows what “no confusion” looks like (a linear system you can read off the picture), the S-box difference and linear tables show where confusion is manufactured, and a letter-frequency panel shows why substitution alone and transposition alone both fall to classical analysis. Ends with where each property lives in AES, DES and ChaCha20.
- Difference propagation
- Avalanche tracer
- Round-by-round dependency
- Key-dependency map
- S-box tables
- Frequency survival
-
SPN Avalanche Lab: design your own S-box
The same 16-bit substitution–permutation network (Stinson's textbook cipher), run twice on inputs that differ in a single bit of the plaintext or the key. Every round is laid out bit by bit with the differences highlighted, so you can watch one flipped bit become two, then seven, then about half the block. The S-box is yours to fill in: type all sixteen entries, or start from the textbook box, PRESENT, identity, a linear map or a random bijection. The page scores your design live — avalanche, differential uniformity, nonlinearity — and a 2000-trial histogram shows whether the full cipher still matches what a random function would do. Try to beat the textbook box, which is decent but not optimal.
- Design your S-box
- Round-by-round trace
- Differing bits per step
- Hamming-distance histogram
- Play round by round
-
AES diffusion: one byte reaches the whole block
Where confusion and diffusion live in a real cipher. Flip a single byte of the AES state and step through the round: SubBytes leaves it in place, ShiftRows carries it across columns, and MixColumns fills the column it lands in — so after one round four bytes are affected, and after two rounds all sixteen. The same walkthrough labels each operation by its role in the substitution–permutation network (SubBytes the substitution, ShiftRows and MixColumns the permutation, AddRoundKey the key mixing) and ends with why AES-128 runs ten rounds and drops MixColumns from the last one.
- Avalanche stepper
- Affected bytes per operation
- SPN role mapping
- Ten rounds and the final round
-
DES avalanche: confusion and diffusion in a Feistel cipher
The real DES, run twice on inputs that differ in one bit. Flip a plaintext bit to see diffusion, or a key bit to see confusion. A 17-row grid then shows the 64-bit state after every round, with each differing bit marked, so you can watch one bit grow to about half the block by round five. Click any round to open it: the expansion wiring, the round key, the eight S-boxes and the P-box are drawn bit by bit, and you can see which S-boxes the difference reaches and how P spreads their outputs. Flip a parity bit of the key to see why DES has only 56 effective key bits.
- Plaintext vs. key bit flip
- Round-by-round difference grid
- Inside one Feistel round
- Where each property lives in DES
-
Differential cryptanalysis on a one-nibble cipher
The attack AES was built to resist, run end to end on a two-round cipher with a single 4-bit nibble of state. Build the S-box's difference distribution table and find the entry that holds half the time; push chosen-plaintext pairs through the cipher and watch the key steps leave the difference untouched while the S-box does or does not cooperate. A diagram then shows why the last round key is the one under attack: the difference predicted forwards from the plaintext and the value computed backwards from the ciphertext meet at the input of the last S-box, and only a guess of K₂ stands in the way. Step through that guess one operation at a time, with every XOR written out bit by bit and every inverse S-box lookup highlighted, for the true key and for a wrong one; then tally hits over all pairs and all sixteen guesses. Click any cell of the table to attack with a weaker differential, or run five hundred random key sets to see how often eight pairs are enough. Closes with the numbers that put the same attack out of reach for AES: a 4-of-256 S-box table and at least 25 active S-boxes in four rounds.
- Difference distribution table
- Chosen pairs through the cipher
- Why the last round key
- Step through one guess
- Worked table and key-guess bars
- Why AES survives
Modes of operation
Week 4 · KL 3.6. A block cipher encrypts one block; a mode decides how to encrypt many of them under one key, and whether equal blocks stay hidden.
-
Same cipher, four modes
One picture, 8,640 AES blocks, one AES-128 key, four modes side by side. Press Encrypt and watch ECB keep the outline of the letter while CBC, OFB and CTR turn it into noise. Encrypt again with a fresh IV and only ECB repeats itself. Then tick “reuse the same IV / nonce”: CBC, OFB and CTR become deterministic too, and for the two stream modes the same key stream lands on both messages, so C ⊕ C′ = M ⊕ M′. AES is implemented in the page and checked against the FIPS-197 test vector when it loads.
- ECB · CBC · OFB · CTR side by side
- Fresh IV vs. reused IV
- What each mode computes
The block-cipher and modes demos also appear in context in Lecture 8 (block ciphers), each placed next to the slide it goes with.