Lion Cipher Lab

Leak a secret across the CPU cache with a Flush+Reload side channel

• Foundations
• Advanced
• ~90 min
• Free · no account required

Why it matters

You can implement a cipher whose math is flawless and still hand an attacker the key -- because the CPU underneath you is quietly narrating what your code does. A cache side channel doesn't factor your modulus or guess your key; it measures a physical fact of the hardware: memory you touched recently is cached, and a cached read is several times faster than an uncached one. Flush+Reload turns that timing gap into a covert channel. An attacker flushes a shared memory line out of the cache, lets your code run, then times how long it takes to read that line back -- if it's fast, your code…

What you'll learn

• What a side channel is: leaking a secret by MEASURING a physical effect (cache-access timing) instead of breaking the math
• CPU cache internals from the ground up: the 64-byte cache line, a cache HIT vs a cache MISS, and why a miss costs several times more cycles
• Cycle-accurate timing with rdtscp plus lfence/mfence serialization, and evicting a line on demand with clflush
• Calibrating a per-CPU hit/miss THRESHOLD from real measured numbers instead of guessing one
• Building a Flush+Reload channel: a page-strided 256-slot probe array shared between a secret-indexed 'victim' and an 'attacker' that flushes, waits, then reloads-and-times every slot
• Recovering a secret byte-by-byte with majority voting over many trials -- repetition beating measurement noise
• Reproducing the hardware-PREFETCHER failure mode on purpose (shrink the stride to 64 B and watch recovery collapse to 0%) and defeating it by striding one slot per 4 KiB page
• Naming the channel's other fragilities: a per-CPU threshold, the requirement for SHARED pages (KSM/page-dedup or a shared file), and unstable rdtsc inside some VMs / WSL2
• The defense and the whole point: constant-time code with no secret-dependent memory access or branch, why AES implementations abandoned secret-indexed T-tables, plus cache partitioning and disabling page dedup

Steps in this lab

1. What a side channel is, in one breath
2. Set up a Linux box (and why WSL2 / a VM may lie to you)
3. Calibrate: see the hit/miss gap with your own eyes
4. Build the channel: a page-strided probe array + a secret-indexed victim
5. Flush, run the victim, reload-and-time: read the secret out
6. Failure mode you reproduce: the prefetcher (why you STRIDE)
7. The channel's other fragilities: threshold, shared pages, VMs, jitter
8. The whole point: constant-time code and the AES T-table lesson
9. The judgment call: 'it's encrypted' is not the same as 'it's safe'

Open the full interactive lab →