What a side channel is
A side-channel attack recovers secret information not by attacking the mathematics of an algorithm, but by observing something about how it runs: how long an operation takes, how much power a chip draws, which memory addresses get accessed (and therefore which CPU cache lines get touched), or even electromagnetic emissions. None of these leaks require breaking AES or RSA mathematically — they exploit the physical reality of the implementation.
Timing attacks in TLS: Lucky Thirteen
The 2013 Lucky Thirteen attack exploited tiny timing differences in how some TLS implementations processed CBC-mode padding — a valid-padding check took a measurably different amount of time than an invalid one, letting an attacker who could send many requests and measure response timing gradually recover plaintext, echoing the Bleichenbacher padding-oracle pattern covered in the RSA padding module but at the symmetric-cipher layer.
Lucky Thirteen, simplified
- 1
Modify a captured ciphertext
The attacker tweaks bytes of an intercepted CBC-encrypted TLS record.
- 2
Resubmit and measure response time
A record with valid padding takes a measurably different code path (and time) to process than one with invalid padding.
- 3
Repeat thousands of times
Statistical averaging filters out network noise from the microsecond-scale timing signal.
- 4
Recover the plaintext byte by byte
Each timing measurement narrows down one byte of the original encrypted data.
Cache-timing attacks
Early software AES implementations used lookup tables for the SubBytes step. Because CPU caches are shared and timing-observable, an attacker running unrelated code on the same physical machine (relevant in cloud/virtualized environments) could sometimes infer which table entries were accessed, and from that recover key bits — a cache-timing attack. This is one of the reasons modern CPUs ship dedicated AES instructions (AES-NI), which execute in constant time regardless of data.
The mitigation: constant-time code
The general defense is constant-time programming: writing cryptographic code so its execution time, memory access pattern, and power draw never depend on secret data — no data-dependent branches, no data-dependent array indexing. This is precisely why cryptography guidelines insist on vetted libraries over custom implementations: constant-time discipline is easy to state and notoriously easy to violate by accident.
Go deeperWhy these attacks need thousands of measurements⌄
A real timing leak is almost never a clean, single measurement — network jitter and OS scheduling noise usually dwarf the microsecond-scale signal an attacker is after. The fix is statistical: averaging N independent measurements shrinks random noise by a factor of √N while the real signal stays put, so the number of samples needed to pull a signal out of noise scales with the square of their ratio.
Worked example: a 2-microsecond timing signal buried in 100 microseconds of network noise needs N = (100/2)² = 2,500 measurements averaged together before the signal reliably separates from the noise — which is exactly why real timing attacks like Lucky Thirteen require sending the same crafted request thousands of times, not once.
Practice
A padding-oracle timing signal is 3 microseconds, buried in 60 microseconds of network noise. About how many measurements need to be averaged to reliably detect it?