---
{
  "title": "Side-channel attacks",
  "summary": "Infer secrets from what an implementation leaks while operating.",
  "topic": "foundations",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "units": [
    8
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Cryptographic Standards and Guidelines",
      "url": "https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

Side-channel attacks exploit observable effects such as timing, power use, electromagnetic signals, or shared-resource behavior. The attacker may infer secret-dependent operations without breaking the mathematical algorithm. Mitigations depend on the threat model and include constant-time implementations, avoiding secret-dependent memory access, isolation, and appropriate physical protections. Use reviewed libraries rather than assuming straightforward code has no leakage.

## In practice

A comparison function returns earlier when an initial byte is wrong, allowing repeated timing measurements to reveal information about a secret value.

## A common misunderstanding

An algorithm’s theoretical security does not guarantee every implementation of that algorithm is secure.

## Check your understanding

Why should secret comparisons avoid early-exit behavior?

**Think it through:** Execution time can reveal information about how much of a guessed value matched.

## Observe the implementation's behavior

A fictional authentication service compares a supplied secret with a stored value. If its comparison stops at the first differing byte, repeated measurements may reveal information about how much matched. The cryptographic design can remain mathematically sound while the surrounding implementation leaks a useful signal.

The relevant signal depends on the environment. Network timing includes noise from scheduling and transport, while a local observer may see shared-resource behavior more directly. Physical access can introduce power or electromagnetic observations. State the attacker's access and measurement capability before deciding which mitigation is appropriate.

Constant-time programming is subtle. Source code that looks balanced can compile into behavior with different timing or memory access. Use reviewed cryptographic libraries and supported comparison functions, and avoid introducing custom secret-dependent branches around them. General application logic may also reveal secrets through error messages or visibly different responses.

## Separate a signal from a conclusion

For a safe learning exercise, draw two fictional comparison algorithms: one that exits early and one designed to avoid content-dependent early exit. Explain the information an observer might seek, without testing against a live service or collecting real secrets. Distinguish the intended property from a claim that all observable behavior is identical.

When evaluating a real concern, document measurement conditions, noise, repeatability, and the practical consequence of the inferred information. A timing difference alone does not automatically establish full secret recovery. The repair should address the specific leakage path and its threat model. This disciplined framing keeps the analysis useful while recognizing that implementation security extends beyond selecting a respected algorithm.

## Keep exploring

- [[cryptanalysis]]
- [[key-management]]
- [[cryptography]]