Power Analysis (SPA/DPA/CPA) — reading a key off a device's power draw

Power analysis recovers a secret key from a device's power-consumption *trace* while it runs a crypto operation: Simple Power Analysis (SPA) reads operations straight off one trace, Differential/Correlation Power Analysis (DPA/CPA) statistically correlates many noisy traces against a leakage model of an intermediate value.

The signal that gives it away

- The challenge ships traces, not just ciphertexts — arrays of float samples per query, usually .npy or CSV, one row (or file) per encryption/signing call. That artifact alone is the tell: nothing else in this wiki hands you raw analog-looking data. - Each trace is paired with a known plaintext/ciphertext for that same query — without a per-trace known input there's nothing to correlate against, so check for accompanying metadata (a pt.npy, a CSV column, a JSON sidecar) before assuming the traces are useless. - Volume is a tell by itself: thousands of traces offered for one fixed key points at DPA/CPA (statistical attack needs many samples to beat noise); a single trace with a clearly repeating visual pattern points at SPA instead (an operation-level leak you can read by eye, no statistics needed). - Textual/contextual tells: "we captured the chip", "power trace", "oscilloscope", explicit mention of Hamming weight, or a target algorithm that's known to have unprotected table lookups (AES with no masking is the flagship target) or unprotected modular exponentiation (RSA/ECC square-and-multiply or double-and-add with no blinding).

How it's exploited

Two genuinely different techniques share the "measure power" premise — pick based on which signal you actually have.

SPA — direct read off one trace. If the underlying algorithm's control flow depends on the secret bit-by-bit (textbook square-and-multiply RSA, double-and-add ECC scalar multiplication with no constant-time guard), each operation type has a visibly different power signature — a multiply draws detectably more power than a square, a point-add stands out from a point-double. Count the pattern of tall/short spikes directly in the trace to read the exponent or scalar bits in one shot, no statistics required (confirmed against Wikipedia's power-analysis page: SPA is "visual examination of graphs of the current used by a device over time", distinguishing operations like square vs. multiply by their electrical signature).

DPA/CPA — statistical correlation across many traces. This is the workhorse when a single trace is too noisy to read by eye, which in practice is almost always the case for table-driven block ciphers like AES. Target the first-round S-box output, sbox[pt ^ k], because it's the earliest point in the computation that mixes a single known-plaintext byte with a single unknown key byte — every later stage mixes in more state and gets harder to isolate. For each of the 256 candidate values of one key byte, compute the Hamming weight of the hypothesized S-box output across all traces, then correlate that hypothesis against the actual power samples at every time point; the correct key-byte guess produces a visibly higher correlation peak than the 255 wrong guesses (this is Correlation Power Analysis, the refined form of DPA — verified against Brier/Clavier/Olivier CHES 2004, and confirmed on Wikipedia's power-analysis page that DPA works by statistically analyzing power measurements across many operations to pull signal out of noise that would defeat SPA):

```python import numpy as np HW = np.array([bin(x).count("1") for x in range(256)])

def recover_byte(traces, pt, b): # traces: (N, T) float samples, pt: (N, 16) known plaintext bytes best, score = 0, -1 for k in range(256): h = HW[SBOX[pt[:, b] ^ k]] # hypothesized leakage under this key guess c = np.abs([np.corrcoef(h, traces[:, t])[0, 1] for t in range(traces.shape[1])]).max() if c > score: score, best = c, k return best

key = bytes(recover_byte(traces, pt, b) for b in range(16)) ```

Run this independently per key byte (16 times for AES-128) — the first-round S-box lookups don't interact with each other, so it parallelizes trivially and each byte recovery is a separate 256-way search rather than one 2^128 search.

Related

Timing Attack — recovering a secret from how long a secret-dependent operation takes Cache-Timing Attack — recovering key bytes from which cache line a table lookup touched Fault Injection Attacks — one faulty RSA-CRT signature factors the modulus outright ECDSA/DSA Nonce Reuse — identical r collapses the private key to closed-form algebra Cryptanalysis Methodology — classify the family before you reach for an attack

What does NOT work

- Correlating against the plaintext or ciphertext bytes directly instead of an intermediate value. The point of targeting sbox[pt ^ k] specifically is that it's the earliest place plaintext and key combine non-linearly under the attacker's control; correlating raw plaintext against traces (skipping the key hypothesis loop entirely) produces no signal because plaintext alone doesn't depend on the key. The key hypothesis has to be baked into the leakage model, not applied after the fact. - Trying SPA-style visual reading on a DPA-shaped problem, or vice versa. A single AES trace with masking/noise almost never shows a readable pattern by eye — burning time squinting at one trace when the challenge clearly hands you thousands is the SPA/DPA confusion to avoid. Conversely, running a full correlation pipeline over one clean square-and-multiply trace is overkill when the exponent bits are just readable directly; check trace count and visual regularity first, before writing any statistics code. - Assuming the leakage model must be Hamming weight. Hamming weight (number of set bits) is the default and most common model and the one field-tested here, but real hardware sometimes leaks Hamming *distance* (bit transitions between consecutive states) instead — if a Hamming-weight CPA gives no clear peak on real captured traces, that's the first thing to swap, not a sign the technique is inapplicable. In a CTF-simulated trace set the challenge author usually matches the model to whatever they documented, so check the challenge description before assuming. - **Treating this as the same problem as Timing Attack — recovering a secret from how long a secret-dependent operation takes or Cache-Timing Attack — recovering key bytes from which cache line a table lookup touched. All three are "side-channel, need many samples, statistics" families and it's easy to reach for the wrong exploitation script — but the measured quantity is different (wall-clock latency vs. cache-line access vs. analog power draw) and so is the leakage model, and mixing them up (e.g. trying to `corrcoef` timing data against a Hamming-weight model meant for power) wastes the setup time without producing a peak. - Expecting real hardware-grade noise handling to matter in a CTF simulation.** Field-tested pattern: CTF power-analysis challenges almost always hand you clean-enough synthetic traces where a straightforward Hamming-weight CPA converges with a few thousand traces; investing in advanced denoising/alignment techniques from the academic literature (needed against actual hardware jitter, trace misalignment, masking countermeasures) is usually wasted effort unless the challenge explicitly says the target is protected/masked.

field-tested, not yet cross-referenced to a public source: the specific trace-count thresholds and "check trace count before choosing SPA vs DPA" heuristic above are our own field observations, not something the cited sources state explicitly — treat them as a starting point, not a guarantee.