Skip to content

CONCEPT Cited by 2 sources

Side-channel attack

Definition

A side-channel attack exploits information leaked by the physical implementation of a cryptographic system rather than a weakness in the algorithm itself. Observable side channels include execution time (timing), power consumption, electromagnetic emanation, cache access patterns, and acoustic signals.

In the context of post-quantum signature deployment, timing side-channel attacks are the primary concern: if signing time varies based on the secret key or message, an attacker who can observe many signing operations can reconstruct the private key.

Microarchitectural / cache side-channels

Beyond cryptographic implementations, side-channels also break isolation boundaries between mutually-distrusting code sharing hardware. The best-known family is Spectre: an attacker abuses the CPU's speculative execution to transiently read out-of-bounds or type-confused memory, encodes one bit into whether a chosen cache line is present, and recovers it via a cache-timing measurement. Here the "side channel" is the CPU cache state, and the leak requires no bug in the victim's architectural behavior — it rides on a hardware optimization. See also tee-side-channel-vulnerability for the same class against confidential-computing enclaves.

Relevance to PQ signatures

  • FN-DSA: Uses floating-point arithmetic for efficient signing. Hardware FPU behavior is processor-specific and poorly understood from a constant-time perspective. A side-channel-safe implementation for one CPU may leak on another. Fixed-point emulation is safe but ~20× slower.
  • SQIsign: Signing is inherently difficult to implement in constant time due to the isogeny computation structure. Performance penalties for safe implementations are severe.
  • ML-DSA: Designed with constant-time implementation in mind; lattice operations are relatively straightforward to implement without timing leaks.

(Source: sources/2026-07-09-cloudflare-post-quantum-signature-algorithms)

Design principle

Cryptographic implementations should run in constant time regardless of input — same code paths, same memory access patterns, same number of operations. Any data-dependent branching or memory access is a potential leak.

Seen in

Last updated · 766 distilled / 2,225 read