a cache-timing attack

A cache is a small fast store that remembers recently used data so the next access is quick; a hit is fast, a miss to main memory is slow, and that speed gap is real and measurable (see cache). A cache-timing attack turns this helpful gap into a leak. The attacker cannot read the victim's secret directly, but the victim's secret influences which memory it touches, which decides what ends up in the shared cache — and the attacker, by timing its own accesses, can tell which lines are warm and so reconstruct what the victim did.

The classic technique is called Flush+Reload, and it works in three steps on memory the attacker and victim share (such as a shared library). First flush: the attacker evicts a chosen cache line so it is guaranteed cold. Then it lets the victim run a little. Then reload: the attacker accesses that same line and times it. A fast access means the victim touched that line (it pulled it back into the cache); a slow access means the victim did not. By choosing lines that correspond to secret-dependent data — say, the entries of a cryptographic lookup table indexed by key bits — the attacker reads out the key bit by bit. A related method, Prime+Probe, fills the cache itself and watches which of its own lines get evicted by the victim.

What makes this so important is that cache timing is the readout mechanism behind the headline speculative-execution attacks. Spectre and Meltdown trick the processor into speculatively loading a secret and using it to index memory; the speculation is rolled back, but the cache line it touched stays warm, and a Flush+Reload then reads that secret out of the cache state (see spectre-vulnerability and meltdown-vulnerability). The honest difficulty is that caches are essential to performance and are shared to be efficient, so the channel is baked into how fast computers work. Mitigations — partitioning caches, constant-time code that never indexes memory by secrets, flushing on context switch — all cost speed.