Abstract

The security proofs of the earlier articles model an idealized black box; a real implementation runs on physical hardware that leaks. This piece frames the side-channel threat model specifically for post-quantum cryptography. It defines the observable channels — timing, power, electromagnetic emanation, microarchitectural state, and induced faults — and then identifies the surfaces that are new to post-quantum schemes and absent from classical ones: the noise samplers, the number-theoretic transform, and the rejection and decapsulation-failure handling. It lays out the spectrum of attacker capabilities, from remote timing over a network to full physical access with fault injection, and distinguishes profiled from non-profiled attacks. The message is that the mathematics is sound, the attack surface is the implementation, and the post-quantum surface is genuinely different and in places larger than the classical one — so defining precisely what an attacker can observe is the first and decisive step. The theme: know your physical adversary before choosing constant-time software or masked hardware.

Every security guarantee in this track assumes an idealized black box that reveals only its inputs and outputs. Real hardware is not a black box: it takes measurable time, draws measurable power, radiates measurable fields, and leaves traces in caches and branch predictors, and each of these can carry information about the secret the box is supposed to hide. Classical cryptography has fought side channels for decades, but post-quantum schemes bring new leaky machinery — samplers that draw noise, the number-theoretic transform that multiplies polynomials, rejection loops that retry — surfaces that simply did not exist in factoring-based cryptography. This article frames the threat model for that new landscape, because choosing the right defenses begins with naming precisely what the physical adversary can see.

What a side channel is

A side channel is any observable physical or microarchitectural quantity that varies with a secret. The security proofs consider only the intended input-output behavior of an algorithm; a side channel is a way the computation betrays the secret through some other, unintended dimension of its execution. The classic channels are timing — how long an operation takes — and power consumption, but the family is broad and includes electromagnetic emanation, the state of shared caches and branch predictors, acoustic and thermal emissions, and the behavior induced by deliberately faulting the computation.

The unifying model is that some measurable quantity is a function of the secret plus noise, and an attacker who can observe that quantity, often across many executions, can statistically recover the secret. A single measurement may reveal little, but averaging over many traces, or correlating measurements against hypotheses about the secret, extracts the signal from the noise. This is why side-channel attacks are usually a matter of collecting enough observations rather than a single clever query.

Crucially, none of this contradicts the cryptographic proofs. A scheme can be perfectly secure against an adversary limited to inputs and outputs and yet fall trivially to one who can time its execution. Side-channel security is a separate, additive requirement layered on top of mathematical security, and it lives entirely in the implementation and the hardware, not in the algorithm's design on paper.

Timing, power and electromagnetic emanation, and induced faults are the principal ways a physical computation betrays its secret. The observable channels Side channelssecret leaks physically Timingduration, cache Power and EMconsumption, fields Faultsinduced errors
Timing, power and electromagnetic emanation, and induced faults are the principal ways a physical computation betrays its secret.
\[\text{observed} = f(\text{secret}) + \text{noise}; \quad \text{recover secret from many observations}\]
\[\text{mathematical security} \ne \text{side-channel security (an additive requirement)}\]

The new post-quantum surfaces

Post-quantum lattice schemes introduce operations with no classical analogue, and each is a new leakage surface. The first is sampling. These schemes must draw small secret values from a specified distribution — a centered binomial for the standardized key mechanism, sometimes a discrete Gaussian elsewhere — and the code that does this can leak: rejection-based samplers take a secret-dependent number of iterations, and table-driven samplers make secret-dependent memory accesses. The very act of generating the noise that secures the scheme can betray it.

The second surface is the number-theoretic transform, the fast polynomial multiplication at the heart of these schemes. Its butterfly operations and modular reductions process secret coefficients, and their power and electromagnetic signatures correlate with those coefficients, making the transform a rich target for physical analysis. The third is the rejection and failure machinery: the signature scheme's rejection-sampling loop retries a secret-dependent number of times, and the key mechanism's decapsulation performs a re-encryption comparison and implicit rejection whose timing, if not carefully handled, reveals whether a ciphertext was valid — a direct oracle.

These surfaces are the reason post-quantum implementation security is not merely classical implementation security reapplied. A factoring-based scheme has modular exponentiation to protect; a lattice scheme has samplers, a transform, and rejection loops, all novel, all leaky, and all requiring their own countermeasures. The attack surface is different in kind, and in aggregate it is larger, which is the central fact a threat model for these schemes must confront.

Noise sampling, the transform's butterflies, rejection loops, and decapsulation-failure handling are surfaces classical factoring-based cryptography never had. Leakage surfaces new to post-quantum schemes Noise samplingrejection or table lookups Number-theoretic transformbutterflies process secrets Rejection and abortssecret-dependent retries Failure handlingdecapsulation oracle
Noise sampling, the transform's butterflies, rejection loops, and decapsulation-failure handling are surfaces classical factoring-based cryptography never had.

The spectrum of attacker capabilities

Not every deployment faces every attacker, and the threat model is defined by what the adversary can physically reach. At the least invasive end is remote timing: an attacker who can only send inputs over a network and measure response times, exploiting timing variations that survive network jitter. Closer in is microarchitectural leakage, where an attacker running code on the same machine — a co-resident tenant in a shared cloud — observes cache and branch-predictor state to infer secret-dependent memory access. These require no physical access at all.

Further along the spectrum, an attacker with physical proximity to the device can measure power consumption and electromagnetic emanation directly, capturing the rich signals of the sampler and the transform. At the most invasive extreme, an attacker with full physical control can inject faults — glitching the clock or voltage, or exposing the chip to radiation — to induce erroneous computations that reveal secrets, and can even decap and probe the silicon. Each step along this spectrum grants more signal and demands stronger, costlier countermeasures.

Placing a deployment on this spectrum is the decisive threat-modeling act. A server in a hardened data center faces remote and microarchitectural attackers, so constant-time software addressing timing and cache leakage is the appropriate bar. A smart card or an edge device an adversary can hold faces the full power, electromagnetic, and fault spectrum, and needs masking and physical countermeasures. Choosing defenses without first fixing the attacker's reach either wastes effort on threats that do not apply or, worse, leaves the actual threat undefended.

From remote timing over a network to full physical fault injection, each step grants more signal and demands stronger countermeasures. How close can the attacker get? Remote timingover the network Cache / localco-resident Power / EMdevice access Fault / invasivefull physical closer physical access, more signal →
From remote timing over a network to full physical fault injection, each step grants more signal and demands stronger countermeasures.

Profiled versus non-profiled attacks

A second axis of the threat model is whether the attacker can profile the target. In a profiled attack — a template attack — the adversary possesses a device identical to the victim's, which it can program with known keys to build detailed statistical models of how the leakage depends on secret values. Armed with these templates, it then needs only a few, sometimes a single, trace from the victim to recover the secret. Profiled attacks are the most powerful and are the relevant model when identical devices are widely available, as with smart cards or consumer hardware.

In a non-profiled attack, the adversary cannot build templates from a clone and must extract the secret from the victim's traces alone, using statistical methods that correlate many measurements against hypotheses about intermediate values. These attacks are weaker per trace and typically need many more observations, but they require no reference device and so apply broadly. The distinction matters because a countermeasure adequate against non-profiled attacks may fall to a profiled one, and the threat model must state which is in scope.

Together with the capability spectrum, the profiling question defines the adversary precisely: how close can they get, and can they profile a clone? These two questions determine everything downstream — how many traces the attacker can gather, how much signal each carries, and therefore how strong the countermeasures must be. A threat model that answers them turns the open-ended fear of side channels into a bounded engineering problem.

📌
Name the adversary first. Two questions define the side-channel threat model: how close can the attacker get (remote timing to physical fault), and can they profile an identical device? The answers select the countermeasures — constant-time software or masked hardware.

Threat modeling as step one

The practical discipline this article argues for is to define the side-channel threat model before writing or selecting an implementation, not after. The threat model states the channels in scope, the attacker's physical reach, and whether profiling is possible, and from that follows the required defense: constant-time execution to close timing and cache channels for a networked server, masking and fault countermeasures for a device in hostile hands. Skipping this step leads either to a false sense of security or to expensive countermeasures aimed at the wrong threat.

It also sets the agenda for the rest of this series. The next article examines the timing channel and the decapsulation oracle in detail, the article after it the power and electromagnetic attacks on the transform and sampler, then the masking countermeasures that defend the physical end of the spectrum, and finally the tooling to verify that an implementation actually meets its constant-time claim. Each addresses a specific region of the threat model framed here.

For autonomous AI systems the threat model has a specific shape worth naming now. A model-serving endpoint or agent that decapsulates ciphertexts is exposed to remote and, in shared infrastructure, microarchitectural attackers, so the decapsulation-timing oracle of the next article is the primary concern and constant-time software the primary defense. Confidential-inference enclaves and agent secret stores that run on hardware an adversary might physically access raise the bar to the power and electromagnetic end of the spectrum, requiring the masking of the fourth article. The guidance is to place each piece of AI infrastructure on the capability spectrum explicitly — networked service versus physically exposed enclave — and to demand the matching class of countermeasure, because a decapsulation oracle on an agent endpoint is exactly where an unmodeled side channel would be exploited.

Key takeaways

  • A side channel is any observable quantity — timing, power, electromagnetic emanation, cache state, fault behavior — that varies with a secret; side-channel security is an additive requirement beyond mathematical security, living in the implementation.
  • Post-quantum lattice schemes add new leakage surfaces absent from classical cryptography: noise samplers, the number-theoretic transform, and rejection and decapsulation-failure handling.
  • These surfaces make post-quantum implementation security different in kind and larger in aggregate than protecting a classical modular exponentiation.
  • The attacker-capability spectrum runs from remote timing over a network, through microarchitectural cache leakage, to physical power and electromagnetic measurement, to invasive fault injection — each step grants more signal.
  • Profiled (template) attacks use a clone device to model leakage and need few traces; non-profiled attacks use only the victim's traces and need many — the threat model must state which is in scope.
  • Define the threat model first — the attacker's reach and profiling ability — because it selects the defenses: constant-time software for networked servers, masking and fault countermeasures for physically exposed devices like inference enclaves and agent secret stores.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

Defining a side-channel threat modelchecklist

State the adversary before choosing defenses.

  • Which channels are in scope: timing, cache, power, electromagnetic, fault?
  • How close can the attacker get: remote, co-resident, physically proximate, invasive?
  • Can the attacker profile an identical clone device (template attack)?
  • Which new post-quantum surfaces (sampler, transform, rejection) does the implementation expose?
  • Does the chosen defense class match the modeled adversary?
🚀Place a deployment on the spectrumquickstart

Map infrastructure to the required countermeasure class.

  • Networked server: expect remote and cache attackers; require constant-time software.
  • Shared/multi-tenant host: add microarchitectural isolation concerns.
  • Physically exposed device or enclave: expect power, EM, and fault attacks; require masking.
  • Widely cloned hardware: assume profiled template attacks.
🔒Side-channel threat-model recordpolicy

A stub capturing the modeled adversary and required defense.

side_channel_threat_model:
  channels_in_scope: [timing, cache, power, em, fault]
  attacker_reach: remote | coresident | physical | invasive
  profiling_possible: true_or_false
  pqc_surfaces: [sampler, ntt, rejection, failure_handling]
required_defense:
  networked: constant_time_software
  physically_exposed: masking_and_fault_countermeasures
Illustrative documentation template, not a product config.

Glossary

Side channel
An observable physical or microarchitectural quantity that varies with a secret, revealing it despite black-box security.
Timing / cache channel
Leakage through how long an operation takes or which memory it touches; exploitable remotely or by a co-resident attacker.
Power / electromagnetic channel
Leakage through a device's power consumption or radiated fields, requiring physical proximity but carrying rich signal.
Fault attack
Inducing errors by glitching clock, voltage, or radiation to make a computation reveal secrets; requires physical control.
Profiled (template) attack
An attack using an identical clone device to build leakage models, then recovering the secret from very few victim traces.
New PQC surfaces
The samplers, number-theoretic transform, and rejection/failure handling that leak in lattice schemes and have no classical analogue.

References

  1. Kocher, Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems (CRYPTO, 1996)
  2. Ravi et al., Side-Channel and Fault Analysis of Lattice-Based KEMs and Signatures (IACR TCHES survey)
  3. NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (2024)
  4. NIST SP 800-227 (draft), Recommendations for Key-Encapsulation Mechanisms
  5. D'Anvers et al., On the Impact of Decryption Failures on the Security of LWE/LWR-Based Schemes (IACR ePrint 2018/1089)