Interactive Demos

Fall 2026 · University of Illinois Urbana–Champaign

Ten browser demos for weeks 1–3 — perfect secrecy, pseudorandomness, semantic security and pseudorandom functions (Katz & Lindell, chapters 2 and 3). 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*)

  One-time pad · information-theoretic security Week 1, Thu 8.27 · KL 2 otp_simulation.html

• 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

  Perfect indistinguishability Week 1, Thu 8.27 · KL 2.1–2.2 indistinguishability-game.html

• 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

  Proof technique · reduction to a distinguisher Week 1, Thu 8.27 · KL 2.1–2.2 build-the-reduction.html

• 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

  Shannon's theorem · key-space bound Week 1–2 · KL 2.3 key-space-bound.html

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}ⁿ → {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

  Pseudorandom generators · the distinguishing game Week 2, Tue 9.1 · KL 3.1–3.3 prg-distinguisher.html

• 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

  PRG ⟹ EAV-secure encryption Week 2, Tue 9.1 · KL 3.3 prg-implies-eav.html

• 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

  Hybrid argument · increasing the expansion factor Week 2, Tue 9.1 · KL 3.3.2 prg-stretch-hybrid.html

• 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

  Hybrid argument · CPA security for multiple encryptions Week 2, Thu 9.3 · KL 3.4 cpa-multiple-encryptions.html

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

  Simulation-based security · leakage functions Week 3 · KL 3.2.2 simulator-leakage.html

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 F_K 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

  Pseudorandom functions · unpredictability and the distinguishing game Week 3 · KL 3.5.1 prf-oracle-room.html