Side-channel attack
In security, a side-channel attack recovers a secret not by breaking the algorithm but by measuring what the implementation leaks while it runs: the time it takes, the power it draws, its electromagnetic emissions, or its effect on a shared cache. It has two faces: hardware in embedded devices, and timing in software.
How it works
A cryptographic algorithm can be mathematically sound and still leak through the way it is implemented. Side-channel attacks measure that leakage. On hardware, an attacker with physical access observes the power a chip consumes or the electromagnetic field it emits while it performs an operation, and because those signals depend on the data being processed, careful analysis over many measurements can recover a key. In software, the leak is usually timing: a comparison or a cryptographic operation whose duration depends on secret data lets an attacker infer that data by measuring how long it takes, and a shared resource such as a processor cache can leak across boundaries the software assumed were isolated. In every case the secret is recovered without ever breaking the cipher.
What goes wrong
The failure is assuming that a strong algorithm makes the implementation strong. On embedded devices, keys that a firmware analysis could not find in storage can still be pulled from a chip through power analysis, which is why high-assurance designs isolate key operations in a hardware security module built to resist exactly this. In software, non-constant-time comparisons of secrets (a token, a signature, a message authentication code) are a recurring finding, because the natural way to write the check leaks through timing. From the attacker’s side, the side channel is attractive precisely because the target defended the algorithm and forgot the implementation.
Where this shows up in an audit
We assess implementation leakage where it matters: on devices, whether keys and secure-boot verification resist physical observation and whether sensitive operations are hardware-protected; in software, whether comparisons of secrets are constant-time and whether shared-resource leakage is possible. Findings are written against the leaking implementation, not the algorithm, since the algorithm is usually fine. The relevance extends to how long a secret must stay safe, which ties to encryption at rest and the migration questions raised by post-quantum cryptography. This is part of how we assess implementation leakage.