The Side-Channel Problem, Attack by Attack: A Practical Breakdown

I’ve spent enough time reading crypto post-mortems to notice a pattern: the algorithm was almost never the weak point. AES wasn’t broken. RSA wasn’t factored. What broke was the implementation — the way a chip drew power, the way a cache line got evicted, the way a comparison function returned a fraction of a millisecond too fast. That’s the side-channel problem, and it deserves to be understood attack by attack rather than as one vague blob called “side-channel attacks.”

In this article I’m going to walk through the major side-channel attack families one at a time — what leaks, how it leaks, how someone captures the leak, and how you close it. No hand-waving, no “just use constant-time code” without explaining what that actually means.

What Counts as a Side Channel?

A side channel is any observable effect of a computation that isn’t the intended output. Cryptographic algorithms are designed so that the output reveals nothing about the secret key. Side-channel attacks ignore the output entirely and instead measure everything happening around it: time, power draw, electromagnetic emission, sound, cache behavior, even error messages.

The core assumption of a side-channel attack is simple: secret-dependent operations produce secret-dependent physical signatures. If a branch is taken only when a key bit is 1, and that branch takes longer to execute, an attacker who can measure execution time precisely enough can recover the key bit.

flowchart TD
    A[Secret Key / Data] --> B[Cryptographic Operation]
    B --> C{Secret-Dependent Behavior?}
    C -->|Yes| D[Physical Signature Leaks]
    D --> E[Timing]
    D --> F[Power Consumption]
    D --> G[EM Emission]
    D --> H[Cache Access Pattern]
    D --> I[Error Messages / Padding Oracle]
    E --> J[Attacker Measures Signal]
    F --> J
    G --> J
    H --> J
    I --> J
    J --> K[Statistical Analysis]
    K --> L[Key Recovery]
    C -->|No, Constant-Time| M[No Exploitable Signal]

Attack 1: Timing Attacks

What leaks: Execution time as a function of secret input.

How it happens: Non-constant-time comparison functions are the classic offender. A naive string comparison for a MAC or password often exits early on the first mismatched byte:

// VULNERABLE - do not use
int insecure_compare(char *a, char *b, int len) {
    for (int i = 0; i < len; i++) {
        if (a[i] != b[i]) return 0; // early exit leaks position of first mismatch
    }
    return 1;
}

An attacker who can submit guesses and measure response time byte-by-byte can recover a MAC or token one byte at a time instead of brute-forcing the whole thing. This turns an astronomically hard brute force into a linear-time attack.

Real-world case: Kocher’s original 1996 paper demonstrated timing attacks against RSA, DSA, and Diffie-Hellman implementations by measuring modular exponentiation time. Since then, timing side channels have surfaced repeatedly — including in TLS implementations (Lucky 13) and in web application login endpoints where password comparisons weren’t constant-time.

Defense:

• Use constant-time comparison functions (hmac.compare_digest in Python, crypto/subtle.ConstantTimeCompare in Go, CRYPTO_memcmp in OpenSSL).
• Avoid secret-dependent branching and secret-dependent memory access.
• Add or normalize response latency at protocol boundaries where constant-time code isn’t feasible.

Attack 2: Power Analysis (SPA and DPA)

What leaks: Instantaneous power draw of a device during computation.

Simple Power Analysis (SPA) reads the power trace directly — different instructions (a multiply vs. a square in RSA’s square-and-multiply) draw visibly different amounts of power, so an attacker can literally read the key bit-by-bit off an oscilloscope trace.

Differential Power Analysis (DPA), introduced by Kocher, Jaffe, and Jun in 1999, is more powerful: it doesn’t need a clean single trace. It collects thousands of traces, guesses a subkey, computes a hypothetical intermediate value, and correlates that hypothesis statistically against the real power traces. The correct key guess produces a spike in correlation; wrong guesses look like noise.

Real-world relevance: DPA is the reason smart cards, payment terminals, and hardware security modules undergo side-channel certification (Common Criteria, FIPS 140-3 physical security requirements). It’s a physical-access attack primarily, which is why it matters most for embedded devices, SIM cards, and IoT hardware.

Defense:

• Masking: split secret values into random shares so no single intermediate value correlates with the key.
• Hiding: add noise, randomize execution order, use constant-power logic gates (dual-rail logic).
• Hardware countermeasures certified under FIPS 140-3 / Common Criteria.

Attack 3: Electromagnetic (EM) Analysis

What leaks: Electromagnetic radiation emitted by circuits during computation, which correlates with the same intermediate values as power analysis — but can often be captured without physical contact, using a small probe near the chip.

EM analysis is functionally DPA’s cousin, but it’s more dangerous in some ways because it doesn’t require inserting a shunt resistor or tapping the power line. Researchers have extracted keys from smartphones and laptops by placing EM probes near the case.

Defense: Physical shielding, the same masking/hiding countermeasures used against power analysis, and reducing signal-to-noise ratio through layout-level design.

Attack 4: Cache-Timing Attacks

What leaks: Memory access patterns via CPU cache state.

Modern CPUs cache recently accessed memory. If a cryptographic implementation’s memory access pattern depends on secret data (e.g., a lookup table indexed by a key byte, as in naive AES T-table implementations), an attacker sharing the same physical CPU (a classic cloud multi-tenancy scenario) can measure cache hit/miss timing to infer which table entries were accessed.

Techniques include:

• Prime+Probe — fill the cache, let the victim run, then measure which cache sets were evicted.
• Flush+Reload — flush shared memory lines, let the victim run, then time reloading them.
• Evict+Time — evict a set, time the victim, infer whether that set was touched.

Real-world case: Cache-timing attacks against naive AES table lookups were demonstrated by Bernstein (2005) and Osvik/Shamir/Tromer (2006), showing full AES key recovery from cache timing alone, no power probes needed — just co-located processes.

Defense:

• Bitsliced or hardware-accelerated AES (AES-NI) that avoids secret-indexed table lookups entirely.
• Cache partitioning / isolation between tenants.
• Constant-time table-free implementations.

Attack 5: Padding Oracle and Error-Message Side Channels

What leaks: Differences in error responses (timing, error codes, or messages) that reveal whether decrypted padding was valid.

This is the software-level cousin of hardware side channels. The Bleichenbacher attack (1998) against PKCS#1 v1.5 RSA padding, and later padding oracle attacks against CBC-mode encryption (Vaudenay, 2002; and the POODLE/Lucky 13 attacks against SSL/TLS), exploit servers that respond differently — even by a few milliseconds — depending on whether padding was valid.

Defense:

• Authenticated encryption (AES-GCM, ChaCha20-Poly1305) instead of encrypt-then-hope padding is checked safely.
• Uniform error handling: same error, same timing, regardless of failure reason.
• MAC-then-verify before any decryption-dependent branching (encrypt-then-MAC construction).

Comparing the Attack Families

Professional Workflow for Side-Channel Risk Assessment

1. Threat model first — decide if the attacker has physical access, co-location, or only network access. This determines which attacks are even feasible.
2. Static review — audit crypto code for secret-dependent branches, secret-dependent array indices, and non-constant-time comparisons.
3. Dynamic testing — use tools like dudect or ctgrind to statistically test for timing leakage in real binaries.
4. Hardware evaluation (where relevant) — power/EM trace capture with tools like ChipWhisperer for embedded targets.
5. Certification — for hardware handling keys, target FIPS 140-3 or Common Criteria side-channel resistance evaluation.

Common Mistakes

• Assuming “we use HTTPS” solves timing attacks — TLS protects data in transit, not implementation-level timing leaks in your own comparison logic.
• Adding a fixed sleep() to “fix” timing attacks — jitter and network noise can still allow statistical averaging over enough samples.
• Believing side-channel resistance is only a hardware concern — cache-timing and padding oracle attacks are pure software problems.

FAQs

Q: Are side-channel attacks only relevant to smart cards and hardware? No. Timing attacks and padding oracles are pure software issues exploitable over a network connection with no physical access at all.

Q: Does using HTTPS/TLS prevent side-channel attacks? It reduces some risk (encrypting timing noise somewhat) but does not eliminate application-layer timing leaks, and TLS implementations themselves have historically had side-channel bugs (Lucky 13).

Q: What’s the single most effective mitigation across all these attacks? Constant-time, secret-independent code paths, combined with authenticated encryption to remove padding oracles. There’s no universal single fix, but this pair addresses the majority of practical cases.

Summary and Recommendations

Side-channel attacks succeed not because cryptography is broken, but because implementations leak information the math never intended to expose. Treat each attack family separately when threat modeling: timing and padding oracles matter for anything network-facing; power and EM analysis matter for physical/embedded devices; cache-timing matters for shared/cloud environments.

Further reading:

• NIST SP 800-90B — Recommendation for the Entropy Sources Used for Random Bit Generation
• OWASP Testing Guide — Testing for Timing Attacks
• MITRE CWE-208: Observable Timing Discrepancy
• Kocher, P. (1996) “Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems”
• Kocher, Jaffe, Jun (1999) “Differential Power Analysis”