Side-Channel and Timing Attacks
You can have a mathematically perfect cipher and still leak the key — not through the algorithm, but through the machine running it. Side-channel attacks exploit the physical shadow a computation casts: how long it takes, how much power it draws, what sound or electromagnetic emission it makes, what it leaves in the cache. The algorithm is sound; the implementation talks. This is one of the most counterintuitive and important ideas in applied security.
The classic: timing attacks
A timing attack infers secret data from how long an operation takes. The canonical example is decades old and still instructive: RSA and similar implementations can leak private keys because the time to perform a modular exponentiation depends on the bits of the secret. Feed the device many chosen inputs, measure the tiny timing differences, and statistics recovers the key one bit at a time — no need to break the math at all.
Smartcards were an early victim: an attacker with physical access sends byte patterns to be signed, times each operation, and correlates the durations (and even the number of set bits in the input) with the internal key-dependent branches. Enough measurements, and the private key falls out.
The everyday version: string comparison
You don't need a smartcard to be vulnerable. The most common timing bug in ordinary software is comparing secrets with a normal equality check, which returns the instant it finds a mismatch:
# VULNERABLE: returns early on first differing byte.
# An attacker measures response time to learn the token prefix-by-prefix.
def check_token(supplied, real):
return supplied == real # short-circuits -> leaks how much matched
# SAFE: constant-time comparison, always examines every byte.
import hmac
def check_token_safe(supplied, real):
return hmac.compare_digest(supplied, real)Every language ships a constant-time comparator (hmac.compare_digest in Python, crypto.timingSafeEqual in Node, subtle.ConstantTimeCompare in Go). Use it for tokens, MACs, and password hashes — anywhere a mismatch is a secret.
The broader family
- Power analysis — measuring current draw (SPA/DPA) to read key-dependent operations; devastating against unprotected embedded devices.
- Electromagnetic — the same idea via radiated emissions, sometimes at a distance.
- Acoustic — yes, the sound of a CPU or coil has leaked keys in lab conditions.
- Cache attacks — Flush+Reload and friends: one process infers another's memory-access pattern by timing shared CPU cache, breaking cross-tenant isolation.
- Speculative execution — Spectre and Meltdown weaponized CPU performance features into cross-boundary leaks, reshaping processor design.
Defenses: make the shadow constant
The unifying principle is eliminate the correlation between secret data and observable behavior:
- Constant-time code — no secret-dependent branches, no secret-dependent memory indices. The runtime must not depend on the secret.
- Use vetted crypto libraries. Do not implement AES or RSA yourself; libraries have spent decades hardening against exactly these leaks. "Don't roll your own crypto" is really "don't roll your own side-channel bug."
- Blinding and masking — randomize inputs (RSA blinding) or split secrets across random shares so measurements reveal nothing.
- Hardware countermeasures — noise, shielding, and dedicated secure elements for high-value keys.
Why it matters even if you're not writing crypto
Two reasons. First, the string-comparison bug is common, easy to introduce, and easy to fix — and it's real: token and signature verification are exactly where it bites. Second, side channels reframe how you think about security: correctness of the algorithm is necessary but not sufficient; the implementation and the hardware are part of the attack surface. A perfect lock on a door with a glass panel is not a secure door.
A flawless cipher can still betray its key through timing, power, or cache. The defense is to make the observable behavior independent of the secret — constant-time code and battle-tested libraries — because the machine, not just the math, is part of your threat model.