Author: Mayckon Giovani
Date: May 2, 2026
Series: PQC Research Series
Tags: PQC, Formal Methods, Cryptography, Systems

TL;DR

“Provably secure” means: if an adversary breaks scheme $\Pi$, then a reduction algorithm $\mathcal{R}$ can solve an underlying problem $P$. Tightness is the quantitative part of that implication: how much advantage and how much runtime are lost when translating an attack on $\Pi$ into a solver for $P$. If the loss factor is large (non-tight), the proof consumes security margin and forces parameter inflation. In PQC, that inflation is not cosmetic: it amplifies bandwidth, RAM, cache pressure, side-channel surface, and failure probability engineering (sampling, rejection, decoding). A reduction is not the system. It is a translation between problems, and translations have loss. (1) (2) (3)

Key takeaways

• Tightness is an engineering input, not a proof-theory detail: loose reductions force larger parameters to recover the target margin.
• A reduction loss factor $f(\lambda)$ costs about $\log_2 f(\lambda)$ bits of security headroom; at scale, $f$ is often driven by query counts ($q_H$, $q_S$) and multi-user/multi-target settings.
• In ROM/QROM, common tactics (forking, rewinding, oracle programming) frequently inject explicit $q_H$-dependent losses; in QROM those losses are harder to avoid and often less tight. (4) (5) (6)
• “NIST level” labels are not proofs: they are the output of cost models (BKZ/sieving heuristics + hardware assumptions) composed with non-tight reduction chains. (7) (8)
• Formal verification can prove that an implementation refines a spec; it cannot repair a loose reduction or a wrong cost model.

0. Context

The PQC conversation in production environments is still dominated by a shallow equivalence:

scheme is “provably secure” $\Rightarrow$ system is secure.

That inference is invalid even before you talk about side-channels or implementation bugs. Security proofs in modern cryptography are conditional, parameterized, and mediated by reductions. The proof does not say “$\Pi$ is secure.” It says “if $\Pi$ is broken with advantage $\varepsilon$ in time $t$, then $P$ is solvable with advantage $\varepsilon'$ in time $t'$.” Tightness is the gap between $(\varepsilon,t)$ and $(\varepsilon',t')$.

The operational consequence is that reductions consume margin. If the reduction is loose, and you want an operational claim like “128-bit confidentiality margin under my threat model,” you must inflate parameters until the reduction loss is absorbed. In lattice cryptography that inflation is paid in large public keys, large ciphertexts/signatures, higher RAM, higher cache traffic, and larger constant-time code paths. That is where “provably secure” becomes either “deployable” or “a lab artifact.”

1. Problem Statement

Fix a security parameter $\lambda \in \mathbb{N}$. Let $\Pi[\lambda]$ be a scheme (KEM, signature, AKE) instantiated at security parameter $\lambda$ and proven secure by reduction to an underlying problem $P[\lambda]$ (DL, RSA, LWE/SIS, etc).

Let $\mathsf{Game}_\Pi$ be the security game for $\Pi$ (IND-CCA, EUF-CMA, AKE, …). Define the adversary’s advantage as usual:

A reduction-based proof typically has the form:

For every adversary $A$ that breaks $\Pi$ with advantage $\varepsilon$ in time $t$ and at most $(q_H, q_S, \dots)$ oracle queries, there exists an algorithm $B$ that solves $P$ with advantage at least $\varepsilon'$ in time $t'$.

The central quantitative question is: how much security is lost in the translation $A \mapsto B$?

Concretely, suppose the reduction $\mathcal{R}$ builds $B$ with oracle access to $A$:

We want to track:

1. advantage loss: a function $g$ such that
   $$\mathrm{Adv}_{P}(B;\lambda) \;\ge\; g(\mathrm{Adv}_{\Pi}(A;\lambda), \lambda, q_H, q_S,\dots),$$
2. time/query overhead: a function $h$ such that
   $$T(B) \;\le\; h(T(A), \lambda, q_H, q_S,\dots),$$
3. and the implicit assumption: that the deployed implementation matches the model in which $\mathcal{R}$ operates (ROM vs standard model vs QROM; single-user vs multi-user; single-target vs multi-target; leakage-free vs leakage models).

The proof is only operationally meaningful after you translate those functions into:

• concrete parameter sizes,
• a concrete attacker cost model,
• and system constraints (RAM/CPU/network/leakage budgets).

2. Formal Model

2.1 Loss factor as an explicit function

In most cryptographic reductions, advantage loss appears as an inequality of the form:

where $f(\cdot)$ is the loss factor and $\Delta(\lambda)$ collects negligible/statistical terms (abort probability, simulation distance, decryption failure, etc).

Equivalently, rearranging the reduction:

The reduction is tight if $f(\cdot)$ is close to $1$ (or at least a small constant / low-degree polynomial with small coefficients) in the regime that matters, and loose if $f$ is large and grows in the relevant operational parameters.

To talk about tightness without hand-waving, define the tightness ratio:

This definition is deliberately adversarial: it asks “how bad can the translation be” for the class of attacks the reduction claims to cover.

2.2 Concrete security translation: loss eats bits

Operationally we do not talk in “$\varepsilon$.” We talk in “bits.” A common concrete-security stance is:

for any feasible attacker $B$ (where $\kappa$ is an effective bit-security function induced by a cost model).

Combining with the reduction gives:

If you want a scheme-level bound like $2^{-\kappa_\Pi}$, you need:

So the security margin you must provision at the assumption layer is:

This is the cleanest way to say what people usually avoid saying: tightness loss is paid as extra bits, and extra bits are paid as CPU/RAM/bandwidth.

2.3 Time overhead and “tight” lies

Advantage is not the only axis. Many reductions amplify runtime:

and $c(\cdot)$ is sometimes large (multiple invocations, rewinding, “guess the right query index,” etc).

Two reductions can have identical advantage loss but radically different runtime overheads. In PQC deployments, runtime overhead affects parameter selection indirectly: if the reduction requires many replays or rewinds, the “feasible adversary” class changes, and the bound becomes meaningless for the time regime you care about.

This is why exact-security work matters: it forces you to write the constants and the query-dependence instead of burying it in “poly.” Bellare–Rogaway-style exact security is the discipline that makes “provable” actually consumable by engineering. (1)

3. System Constraints

In a clean paper model, the only resource is “polynomial time.” In a deployed system, the constraint set is a vector:

Loose reductions push parameters up, which pushes every component of that budget:

• bandwidth/packetization: larger public keys and signatures fragment handshakes and stress middleboxes;
• RAM/cache: lattice arithmetic is memory-hungry; larger parameters increase cache-miss leakage and constant-time difficulty;
• latency: slow verification/signing affects consensus nodes, IIoT gateways, VPN concentrators;
• entropy: many PQC schemes are randomness-intensive; constrained RNG becomes a first-class failure mode (especially at boot);
• side-channel surface: larger code, more branches, more table accesses, more sampling logic → more leakage opportunities;
• failure probability engineering: rejection sampling, decoding failures, and “abort on overflow” logic must be bounded and monitored.

This is why the engineering question “is the reduction tight?” is not academic. It decides whether the parameters that make the theorem true still fit inside the machine you actually ship.

4. Core Argument / Insight

4.1 Why tightness matters operationally (security margin is a consumable)

Assume you are targeting a concrete security bound $\kappa_\Pi$ against a realistic attacker class. The proof gives you:

Now instantiate the operational reality:

• $q_H$ is not “small.” In protocols, hashes are everywhere: transcript hashing, domain separation, commitments, PRF/KDF usage, key schedules, prehashing, merkleization.
• multi-user and multi-target settings are the norm: a production system runs at scale, across many sessions, many keys, many certificates, many handshakes.

So $f$ is often dominated by terms like:

The punchline: the scheme’s “bit security” is not the assumption’s “bit security.” The proof spends some of it.

To make this concrete, consider a reduction with loss $f = q_H^2$. If a verifier in a large system induces (directly or indirectly) $q_H \approx 2^{20}$ effective oracle interactions per security epoch (not insane in transcript-heavy protocols), then:

Forty bits of headroom is not a rounding error. In lattices, forty bits is the difference between “fits in your MTU / fits in your L2 cache” and “now you have to redesign the protocol framing, the packetization, and the implementation strategy.”

If you do not do this translation explicitly, “provably secure” becomes a word that hides debt.

4.2 Example — Fiat–Shamir losses (tightness is often query-driven)

Fiat–Shamir (FS) is a canonical place where tightness is visible because the proof must account for the adversary’s random oracle queries. This matters in PQC because a large fraction of deployed post-quantum signatures and ZK systems are FS-shaped, and Part 3 already established that QROM makes the proof obligations sharper. (5) (9)

Classical ROM: forking-style losses

In ROM, security proofs for FS-based signatures often rely on the forking lemma (Pointcheval–Stern). The structure is:

1. Run the forger $A$ once, record its oracle queries.
2. Rewind $A$ with the same randomness, but answer one targeted oracle query differently.
3. If you get two valid transcripts with different challenges, extract the witness / discrete log / solution.

This almost always introduces a loss driven by the probability that you “hit the right query” and by the probability that the adversary forges at all. Exact-security analyses make this explicit; for Schnorr-type signatures, the reduction loss is at least linear in the number of hash queries $q_H$, and in many cases that loss is essentially optimal. (4) (10)

At an abstract level, a typical bound has the shape:

depending on the exact extraction strategy, the security definition, and whether you count rewinds in time.

The important engineering fact is not the exact exponent. It is that $q_H$ appears in the denominator. Large protocols induce large $q_H$.

QROM: the loss profile worsens unless you change technique

In QROM, the adversary can query $H$ in superposition. That breaks the classical mental model “record all queries and pick one to program.” Rewinding is not generic; programming the oracle is global; and the simulation must be careful about measurements and disturbance. (3) (11)

That is exactly why the QROM FS literature developed new tools (measure-and-reprogram, compressed oracle, adaptive reprogramming). Those tools exist, but they move the reduction burden into more complex bounds, and tightness is often where the cost shows up. (9) (6)

The practical lesson is not “avoid FS.” The lesson is: treat $q_H$ and reduction tightness as first-class protocol parameters. If you do not control oracle query surfaces (transcript structure, domain separation, protocol framing), you are implicitly paying in security margin.

4.3 Lattice cryptography and non-tight reduction chains

Lattice-based schemes (ML-KEM, ML-DSA, Falcon, and many variants) inherit two distinct kinds of non-tightness:

1. worst-case/average-case reduction losses (approximation factors and parameter regimes),
2. scheme-level transforms (e.g., turning CPA into CCA, ROM/QROM indirections, multi-target scaling).

Worst-case to average-case: approximation-factor inflation

The foundational LWE story is “average-case LWE is as hard as worst-case lattice problems,” but the reduction does not preserve the approximation factor tightly. In a typical regime:

That $\gamma(n)$ term is not a constant. It is an inflation factor in the hardness statement, and it is one of the reasons “security level” estimates are not cleanly derivable from a theorem. (12) (2)

Concrete security is cost-model + reduction chain

At the deployment layer, you do not size parameters from a reduction alone. You size them via:

For lattices, the attack model is dominated by BKZ/sieving-style heuristics, and the mapping to “bits” is done by tools like the lattice estimator. (7) (8)

That means a PQC “security category” is not a theorem. It is a statement about a stack of assumptions:

• the underlying lattice problem hardness (for quantum or classical attackers),
• the accuracy of BKZ/sieving cost models (time vs memory vs parallelism),
• the translation from those costs to your adversary budget,
• plus the reduction loss factors incurred by your scheme transform and protocol embedding.

This is not pessimism. This is the minimum honest structure of the claim.

4.4 The security margin illusion (why “Category 5” can still be fragile)

The industry likes crisp labels: “128-bit,” “Category 3,” “PQC-ready.” In practice:

1. security margins move when cost models move;
2. reductions move when the oracle model changes (ROM vs QROM) or when the environment changes (single-user vs multi-user);
3. deployments move when system constraints force optimizations that violate proof assumptions (biased sampling, caching secrets, skipping constant-time discipline).

Even for standardized schemes, the operational story is dominated by system budgets. ML-DSA (FIPS 204) produces signatures in the kilobyte range, and SLH-DSA (FIPS 205) produces signatures in the multiple kilobyte to tens of kilobyte range depending on parameter set; those are not philosophical costs, they are MTU, log storage, and firmware-update costs. (13) (14)

4.5 Tightness vs deployability (the engineering boundary)

If you want to treat tightness as an engineering artifact, you need to model the whole chain:

flowchart LR
  A["Assumption hardness (P)"] --> B["Reduction loss f(lambda, qH, N, ...)"]
  B --> C["Scheme parameters (sizes, rates, failure bounds)"]
  C --> D["Implementation artifacts (CPU, RNG, memory, constant-time)"]
  D --> E["Operational envelope (latency, MTU, telemetry, incident response)"]

Loose reductions apply pressure at step (B). Pressure then propagates through (C) and (D) into (E). That is the honest reason “provably secure” does not mean “deployable.” Deployment is a boundary condition on parameters; tightness decides whether you can satisfy it without lying.

4.6 Embedded / edge consequences (where loose reductions become safety hazards)

Edge environments (IIoT gateways, Cortex-M-class devices, industrial controllers) do not fail gracefully under parameter inflation:

• RAM is measured in kilobytes; stack spills are crashes.
• cache behavior is not noise; it is a leakage oracle.
• timers are coarse; constant-time costs are amplified.
• entropy at boot is weak; randomness reuse is a realistic failure mode.
• power is a security channel (power analysis) and a reliability constraint (brownouts).

So a reduction that “only” costs $\Delta\kappa$ bits often translates into:

• larger polynomials/NTT buffers,
• more sampling work per signature,
• more memory traffic per verification,
• and a larger surface for side-channel and fault attacks.

This is not theoretical. It is the lived reality of trying to ship PQC in adverse environments.

4.7 Formal verification cannot fix loose reductions

Formal verification is the right tool for proving:

• memory safety / absence of UB,
• refinement between spec and implementation,
• constant-time properties (under a model),
• protocol state-machine invariants,
• deterministic behavior under concurrency constraints.

It cannot prove:

• that the reduction $f(\cdot)$ is tight,
• that your parameter sizing is adequate under the evolving lattice attack landscape,
• that your threat model is aligned with the oracle interface (ROM vs QROM),
• or that your cost model matches the attacker’s hardware and parallelism budget.

Formal verification can ensure you implemented the scheme you specified. It does not validate the meta-assumptions that connect that scheme to a concrete “bits of security” statement. If the reduction is loose, you are still forced into parameter inflation; if the cost model is wrong, you are still exposed; if the threat model is wrong, your proof is still irrelevant.

4.8 Case studies: ML-DSA, Falcon, SLH-DSA (different failure modes, same tightness problem)

ML-DSA (Dilithium lineage): reasonable performance, big artifacts

ML-DSA is engineered for relatively efficient signing/verification compared to many alternatives, but signatures and public keys are large enough to be operationally visible. When tightness losses force parameter inflation, the first thing that breaks is not “the theorem.” It is certificate chains, protocol framing, and embedded memory budgets. (13)

Falcon: smaller signatures, fragile implementations

Falcon’s attraction is compact signatures, but the implementation surface is correspondingly sharper: floating-point hazards, subtle side-channel vectors, and constant-time difficulty can dominate the risk profile. Tightness does not save you if the system cannot preserve the model boundary. (This is why NIST treats Falcon as an additional standardization track rather than “the default.”) (15)

SLH-DSA (SPHINCS+ lineage): conservative assumptions, brutal operational cost

SLH-DSA is attractive as a non-lattice hedge, but it is operationally heavy. Loose reductions are not the main story here; the story is that even with conservative assumptions, the deployment cost is so high that teams will be tempted into unsafe shortcuts (truncation, caching, under-verified paths). Tightness and deployability are still linked: if your system cannot tolerate the overhead, you will violate assumptions. (14)

4.9 The core argument

Tightness determines whether security survives reality.

A proof without a deployable tightness profile is a claim about an object you cannot safely instantiate at scale. In PQC, that gap becomes visible because artifacts are big and the system boundary is tight: bandwidth, RAM, and leakage are not optional.

If you want a professional security claim, you must treat tightness as a first-class design constraint, and you must show how parameter sizing absorbs the loss without collapsing system safety.

5. Implications

1. Reduction loss must be part of the spec. Document $f(\lambda, q_H, N, \dots)$, not just the underlying assumption.
2. Query surfaces must be engineered. Protocol framing, transcript structure, and domain separation are not “implementation details.” They determine $q_H$.
3. Concrete security must be treated as a living artifact. BKZ/sieving and hardware models move; you need telemetry and a reparameterization plan.
4. Hardware-aware co-design is mandatory. If your target includes constrained nodes, assume that parameter inflation will push you into leakage and correctness failure modes.
5. Formal verification remains necessary but insufficient. It closes the spec→binary gap; it does not validate the reduction→bits→ops gap.

6. Continuity Hook

Part 5 will focus on leakage-aware adversarial models and the “constant-time fallacy”: how side-channel interfaces turn clean reductions into irrelevant statements, and how to treat constant-time and erasure as formal properties rather than best-effort hardening.

7. References

Evidence

• Exact-security framing and why constants/tightness matter: Bellare–Rogaway. (1)
• Forking lemma and ROM-era tightness limits in FS-shaped signatures: Pointcheval–Stern; Seurin. (4) (10)
• QROM shifts the proof interface and changes tightness profiles: Boneh et al.; Unruh; Don et al.; Grilo et al. (3) (5) (9) (6)
• Concrete lattice attack cost modeling is heuristic and must be composed with reductions: Chen–Nguyen; the lattice estimator. (7) (8)
• Standardized PQC schemes have nontrivial artifact sizes that turn tightness into operations: FIPS 204 / FIPS 205. (13) (14)

Checklist

• For every claim, write the full implication: attack on $\Pi$ $\Rightarrow$ solver for $P$, with explicit $(\varepsilon,t,q_H,N)$ dependence.
• Compute $\Delta\kappa \approx \log_2 f$ and provision that headroom explicitly in parameter sizing.
• Treat $q_H$ as a protocol parameter (transcript structure, domain separation, aggregation strategy).
• Validate that parameter inflation does not violate system budgets (MTU/RAM/cache) and does not force unsafe shortcuts.
• Keep a reparameterization playbook: telemetry, versioned suite IDs, and removal deadlines for legacy parameter sets.

Further reading

• Bellare–Rogaway, “The Exact Security of Digital Signatures: How to Sign with RSA and Rabin” (1996). (1)
• Pointcheval–Stern, “Security Proofs for Signature Schemes” (EUROCRYPT 1996). (4)
• Seurin, “On the Exact Security of Schnorr-Type Signatures in the ROM” (ePrint 2012/029). (10)
• Boneh et al., “Random Oracles in a Quantum World” (ePrint 2010/428). (3)
• Unruh, “Post-Quantum Security of Fiat-Shamir” (ePrint 2017/398). (5)
• Don–Fehr–Majenz–Schaffner, “Fiat-Shamir in the QROM” (ePrint 2019/190). (9)
• Grilo–Hövelmanns–Hülsing–Majenz, “Tight Adaptive Reprogramming in the QROM” (ePrint 2020/1361). (6)
• Peikert, “A Decade of Lattice Cryptography” (2016). (2)
• Chen–Nguyen, “BKZ 2.0” (ASIACRYPT 2011). (7)
• LWE estimator. (8)
• NIST FIPS 204 (ML-DSA). (13)
• NIST FIPS 205 (SLH-DSA). (14)

Author: Mayckon Giovani
Date: April 30, 2026
Series: PQC Research Series
Tags: PQC, Formal Methods, Cryptography, Systems

TL;DR

Security proofs built in ROM assume an oracle interface that quantum adversaries do not respect. In QROM the adversary can query the hash/KDF in superposition, which makes “record all queries,” “rewind,” and “program the oracle at $x^\star$” fundamentally different operations. Fiat–Shamir survives in many important cases, but the proof obligations are sharper, the reductions are typically less tight, and the system boundary (what is actually quantum-queryable) becomes part of the security statement. (1) (2) (3) (4)

Key takeaways

• QROM is a different oracle interface, not a stronger attacker in the same interface.
• In ROM, “lazy sampling + programming + rewinding” is a standard reduction toolbox; in QROM the same words denote operations that disturb the adversary state or require nontrivial bounds.
• Fiat–Shamir in QROM is possible but conditional: extraction is not generic, and tightness can degrade sharply.
• Systems matter: if your hash is public and deterministic, you should assume quantum-accessible evaluation (coherent implementation), even if the endpoints are classical.
• If your model boundary is wrong, your proof is irrelevant.

0. Context

ROM is “too useful” in practice: it turns hash functions into ideal objects and lets us prove security for transforms and protocols that are otherwise intractable. A large fraction of deployed cryptography (including most Fiat–Shamir-based signatures and many non-interactive ZK stacks) still leans on ROM-style reasoning.

The problem is that ROM assumes a classical interface to the oracle. In 2026 this is no longer the conservative model for any public, deterministic function (SHA-2/SHA-3/BLAKE2/BLAKE3, KDFs, transcript hashes): a quantum adversary can implement those circuits coherently and query them in superposition. That interface shift is exactly what QROM captures. (1)

Security proofs built in ROM assume an interface that quantum adversaries do not respect.

1. Problem Statement

Let $\lambda \in \N$ be the security parameter. Fix an output length $\ell(\lambda)$ and consider a random oracle $H$ as an idealized hash/KDF:

In classical ROM, an adversary $\adv$ is a PPT oracle machine that makes a sequence of classical queries $x_1,\dots,x_{q}$ and receives classical answers $H(x_i)$.

The security statement of a scheme $\Pi$ in ROM has the familiar shape:

Now change only one thing: the adversary is quantum polynomial-time and can query $H$ coherently in superposition. The right object is no longer a “function oracle” but a unitary oracle $U_H$.

The problem is then:

What changes when the adversary can query the oracle in superposition?

Formally, we want to understand how the advantage bound, the reduction technique, and the proof obligations change when we move from ROM to QROM:

The answer is not “add Grover factors.” The answer is: the proof techniques themselves stop being valid unless reworked. (1) (2)

2. Formal Model

2.1 Classical ROM — Formal Definition

2.1.1 Oracle definition and interaction

In ROM, the challenger samples a function $H$ uniformly from the set of all functions $\{0,1\}^\ast \to \{0,1\}^{\ell(\lambda)}$. The adversary interacts via classical queries:

The standard implementation of ROM in proofs is lazy sampling: $H(x)$ is defined on first query and stored in a table.

state T : map from {0,1}* to {0,1}^ℓ

Oracle H(x):
  if x ∈ dom(T): return T[x]
  y ←$ {0,1}^ℓ
  T[x] := y
  return y

This is the object that enables classical ROM proof moves.

2.1.2 Classical proof moves in ROM

ROM reductions frequently rely on three operations:

1. Observe queries. The reduction records every $x$ queried to $H$.
2. Reprogram the oracle. The reduction sets $H(x^\star) := y^\star$ after seeing some adversary behavior.
3. Rewind. The reduction replays the adversary from a previous point with modified oracle responses to extract a witness (forking lemma style).

These moves are not “syntactic conveniences.” They are model-level assumptions about the oracle interface.

2.2 QROM — Formal Shift (where the pain starts)

2.2.1 Unitary oracle interface

In QROM, the oracle is a unitary operation over two registers:

A QROM adversary $\adv_Q$ is a QPT algorithm (poly-size uniform quantum circuits) that can interleave its own unitaries with calls to $U_H$:

The observable object is not a query transcript. It is a final classical measurement outcome after a sequence of coherent operations.

One subtlety that matters for proofs: in ROM, “lazy sampling” gives a concrete simulation strategy for $H$ without ever materializing the full random function. In QROM, you still conceptually sample a random function $H$, but the adversary’s access is through a unitary $U_H$ that must behave consistently on superpositions. Naively “defining $H(x)$ on demand” is no longer a complete description of how the oracle acts, because the simulator cannot simply observe which $x$ values are being queried.

This is the gap that QROM techniques bridge: they construct simulators and hybrid arguments that bound what a $q$-query quantum adversary can learn or distinguish about changes to $H$ without requiring an impossible transcript log. (1) (2)

2.2.2 Why “recording queries” is not a primitive

Consider a single query state in the $x$-register:

After the oracle call:

The query register is now entangled with the answer register. If the reduction measures the query register to “see which $x$ was asked,” it collapses the state and changes the adversary’s future behavior. There is no free transcript.

You can make this quantitative with the right notion of “disturbance.”

Let $x^\star$ be a point you care about (e.g., the fork point, the programmed point). Define the projector $P = |x^\star\rangle\langle x^\star|$ on the query register and let:

If you measure the two-outcome POVM $\{P, I-P\}$ and discard the outcome, you obtain a mixed state $\rho$. The trace distance to the original state is bounded by a term on the order of $\sqrt{p}$ (formal constants depend on the exact measurement map, but the scaling is the key): if the adversary assigns negligible amplitude to $x^\star$, then “checking whether $x^\star$ was queried” can be a gentle operation; if it assigns non-negligible amplitude, measurement meaningfully perturbs the computation. (For the standard trace-distance/fidelity calculus underlying these bounds, see e.g. Nielsen–Chuang and the Fuchs–van de Graaf inequalities.) (5) (6)

That is the deep point: in QROM, “did it query $x^\star$?” is not a boolean event. It is an amplitude question.

This is why ROM techniques need replacement lemmas (compressed oracle, measure-and-reprogram, quantum rewinding variants) instead of direct reuse. (2) (7)

flowchart LR
  A["ROM reduction"] --> T["classical transcript"]
  A --> P["point programming at x_star"]
  A --> R["rewinding / forking"]
  Q["QROM adversary state (ket psi)"] --> X["measurement disturbance"]
  X --> T
  X --> R
  Q --> UH["unitary oracle U_H"]

2.3 Where Classical Proof Techniques Break

2.3.1 Rewinding fails (in general)

Classical rewinding assumes you can replay $\adv$ from a previous internal state. Quantum algorithms do not expose their internal state without measurement, and measurement is destructive.

More formally, let the adversary’s internal state at some point be $|\psi\rangle$. Any attempt to “copy” $|\psi\rangle$ violates no-cloning, and any attempt to “observe” it induces a measurement map $\mathcal{M}$ that changes the state.

There are quantum rewinding techniques (Watrous-style) that work for restricted protocol structures (public-coin, certain ZK settings), but they are not a generic replacement for the classical forking lemma pipeline used in ROM proofs. In other words: the extraction interface changes. (7)

2.3.2 Programming the oracle is a global operation

In ROM, reprogramming is local: define $H(x^\star)$ late, or change it, and reason about the probability that $\adv$ queried $x^\star$.

In QROM, reprogramming is not local in the same way because the adversary can query $x^\star$ with small amplitude across many coherent queries.

A standard quantitative intuition is captured by “hybrid” bounds for quantum queries: if two oracles $H$ and $H'$ differ on a small set of inputs, then any $q$-query QPT distinguisher has advantage bounded by a term that scales like $q\sqrt{t/|D|}$ (domain size $|D|$, difference set size $t$). In the single-point case ($t=1$), the effect of changing one value is upper bounded by $\tilde{O}(q/\sqrt{|D|})$. This is the same phenomenon behind Grover optimality bounds. (8)

To make that concrete, fix a finite domain $D$ with $|D|=N$ and consider two random oracles $H,H'$ that are identical everywhere except at a single point $x^\star$ where $H(x^\star)\neq H'(x^\star)$. Then any quantum algorithm $\adv_Q$ making at most $q$ quantum queries to the oracle satisfies an inequality of the form:

up to constant factors (and with extensions to $t$-point differences). This is exactly why point programming needs amplitude accounting in QROM rather than transcript accounting in ROM. (8)

The same bound is a useful engineering sanity check: it shows when “reprogramming one point” is statistically invisible versus when it is potentially detectable.

xychart-beta
    title "Single-point oracle difference bound (toy scaling)"
    x-axis ["0","40","80","120","160","200","240","280","320","360","400","440","480","520","560","600","640","680","720","760","800"]
    y-axis "O(q/√N)" 0 --> 1
    line "N = 2^20" [0.0,0.039063,0.078125,0.117188,0.15625,0.195313,0.234375,0.273438,0.3125,0.351563,0.390625,0.429688,0.46875,0.507813,0.546875,0.585938,0.625,0.664063,0.703125,0.742188,0.78125]
    line "N = 2^40" [0.0,0.000038,0.000076,0.000114,0.000153,0.000191,0.000229,0.000267,0.000305,0.000343,0.000381,0.000420,0.000458,0.000496,0.000534,0.000572,0.000610,0.000648,0.000687,0.000725,0.000763]

This bound is both good news and bad news:

• good: small reprogrammings can be statistically invisible up to a regime,
• bad: you cannot justify “it didn’t query $x^\star$” by reading a transcript, because there is no transcript.

Zhandry’s “compressed oracle” technique is one of the key tools that makes these arguments precise: instead of logging queries, you reason about the adversary’s interaction with an evolving classical description of a quantum-accessed oracle. (2)

2.3.3 Fiat–Shamir starts to crack

Fiat–Shamir (FS) takes an interactive proof/identification protocol and replaces the verifier’s random challenge with a hash of the transcript. In ROM this is natural: a random oracle is a model of “perfect challenge generation.”

In QROM, the adversary can query the oracle in superposition before committing to a transcript, and it can maintain quantum state that is entangled with oracle answers. This breaks the standard ROM proof skeleton:

• the extractor cannot reliably fork by rewinding,
• programming $H$ at one point is not a benign point change without extra reasoning,
• and “the adversary must have queried $H$ at the forgery point” is no longer a classical event you can check by inspecting a log.

The result is not that FS is “broken.” The result is: classical FS proofs do not lift automatically. You need QROM-aware arguments and, often, additional conditions on the underlying protocol (special soundness, commitment structure, etc.). (3) (4)

2.4 Deep Dive — Fiat–Shamir in a Quantum World

2.4.1 $\Sigma$-protocol model

Consider a (public-coin) $\Sigma$-protocol for relation $\mathcal{R} \subseteq \mathcal{X}\times\mathcal{W}$ where $x\in\mathcal{X}$ is a statement and $w\in\mathcal{W}$ is a witness.

The interactive protocol is:

1. Prover samples randomness $\rho$ and sends commitment $a \leftarrow \textsf{Commit}(x,w;\rho)$.
2. Verifier samples challenge $c \leftarrow \{0,1\}^k$ and sends $c$.
3. Prover sends response $z \leftarrow \textsf{Respond}(x,w;\rho,c)$.
4. Verifier checks $\textsf{Verify}(x,a,c,z)=1$.

Special soundness (the typical extraction property) says:

2.4.2 Fiat–Shamir transform

FS removes the verifier by setting:

for message $m$ (for signatures) or context string. The prover outputs $(a,z)$ and the verifier recomputes $c$ from $H$.

In ROM, a standard security proof sketch for FS-based signatures is:

1. assume a forger outputs a valid transcript $(a,z)$ for $c=H(\cdot)$,
2. by forking (rewinding with different oracle programming) obtain two transcripts with same $a$ and different $c$,
3. apply special soundness to extract $w$.

This pipeline depends on an extractor that can:

• observe whether/when the forger queried $H$ at $(x,a,m)$,
• program $H$ at that point to force a different $c'$,
• rewind the forger to re-run with the modified oracle.

2.4.2.1 A QROM-flavored EUF-CMA game (what you are actually claiming)

To avoid hand-waving, write the security claim in a game form that matches deployment reality.

An FS-based signature scheme $\Sigma_{\textsf{FS}}$ (built from a $\Sigma$-protocol) is typically verified under EUF-CMA:

• $\textsf{KeyGen}(1^\lambda)$ outputs $(\mathsf{pk},\mathsf{sk})$ where $\mathsf{pk}$ is the statement and $\mathsf{sk}$ is the witness.
• $\textsf{Sign}(\mathsf{sk},m)$ runs the prover to produce $(a,z)$ with challenge $c := H(\mathsf{pk},a,m)$ and outputs $\sigma := (a,z)$.
• $\textsf{Verify}(\mathsf{pk},m,\sigma)$ recomputes $c := H(\mathsf{pk},a,m)$ and checks $\textsf{Verify}_\Sigma(\mathsf{pk},a,c,z)=1$.

The QROM security game then looks like:

1. Challenger samples $(\mathsf{pk},\mathsf{sk})$ and a random oracle $H$.
2. $\adv_Q$ is a QPT adversary with quantum oracle access to $U_H$ and classical access to a signing oracle $\textsf{Sign}(\mathsf{sk},\cdot)$.
3. $\adv_Q$ outputs $(m^\star,\sigma^\star)$.
4. $\adv_Q$ wins iff $\textsf{Verify}(\mathsf{pk},m^\star,\sigma^\star)=1$ and $m^\star$ was not previously signed.

Define advantage:

The key detail is the mixed interface: the adversary has quantum access to $H$ (because $H$ is public and coherently computable) but only classical access to the signer (because signing is an external system interface). This mixed typing is not a nuance — it is what makes many reductions either possible or impossible. (1) (3)

2.4.3 Why the extractor is not generic in QROM

In QROM, the forger can query $H$ in superposition on many candidate $(x,a,m)$ values, potentially entangled with its internal randomness and commitments.

There is a core impossibility shape here: for general FS instantiations, black-box extractors of the classical type do not exist in QROM without additional structure. The reason is precisely that “the fork point” is not a classical observable event. Extraction requires different techniques (quantum rewinding variants, measure-and-reprogram, compressed oracle arguments) and tends to be protocol-specific. (3) (4)

2.4.4 A concrete quantitative lens: Grover-style query economics

Even before extraction, QROM changes the economics of oracle access. Many ROM security arguments implicitly assume a classical $q$-query adversary cannot do much better than $q/|D|$ for preimage-style events. In QROM, unstructured search admits quadratic speedup with $O(\sqrt{|D|})$ queries (Grover), and this is optimal (BBBV). (9) (8)

This does not “break” FS by itself, but it changes the bound calculations that sit under heuristic security-level claims.

Below is a simulation of success probability for preimage search on a domain of size $N=2^{20}$, comparing a classical $q$-query strategy ($p \approx q/N$) versus ideal Grover amplitude amplification ($p=\sin^2((2q+1)\arcsin(1/\sqrt{N}))$).

xychart-beta
    title "Preimage search success probability (N = 2^20)"
    x-axis ["0","40","80","120","160","200","240","280","320","360","400","440","480","520","560","600","640","680","720","760","800"]
    y-axis "Pr[success]" 0 --> 1
    line "Classical q/N" [0.0,0.000038,0.000076,0.000114,0.000153,0.000191,0.000229,0.000267,0.000305,0.000343,0.000381,0.000420,0.000458,0.000496,0.000534,0.000572,0.000610,0.000648,0.000687,0.000725,0.000763]
    line "Grover" [0.0,0.003055,0.012204,0.027373,0.048452,0.075300,0.107744,0.145579,0.188571,0.236456,0.288945,0.345723,0.406451,0.470767,0.538291,0.608624,0.681356,0.756065,0.832321,0.909688,0.987729]

Two notes for engineers reading this:

1. This is a toy curve about oracle-query economics. It is not a complete security argument for any specific scheme.
2. It is exactly the kind of difference that turns “ROM intuition” into “QROM accounting.” If the proof’s hidden constant is “adversary must query $H$ at $x^\star$,” you need to reason about quantum query amplitude, not classical query events.

2.5 Attempts to Fix the Problem (what actually works)

The literature does not stop at criticism. There is a well-developed toolchain for QROM reasoning, but it is heavier and more conditional than ROM reasoning.

2.5.1 Compressed oracle and query recording

Zhandry’s compressed oracle framework gives a way to reason about quantum queries by representing the oracle state as a compressed classical structure plus a bound on how much information a $q$-query adversary can extract. This underpins a number of indifferentiability and reprogramming arguments in QROM. (2)

2.5.2 QROM Fiat–Shamir proofs (Unruh; Don–Fehr–Majenz–Schaffner)

Unruh established QROM security of Fiat–Shamir under conditions that essentially replace the classical forking lemma with a quantum-aware argument (often called a “quantum forking lemma” in informal discussion). (3)

Don et al. refine and systematize the analysis of FS in QROM, providing proofs (and clarifying limitations) for broad classes of $\Sigma$-protocols and related transforms. (4)

2.5.3 Quantum rewinding (Watrous)

Watrous showed that certain zero-knowledge proofs remain secure against quantum adversaries using specialized quantum rewinding. This is not a generic drop-in for classical rewinding, but it demonstrates that the right structure can make extraction/simulation possible. (7)

3. System Constraints

Systems, not just proofs

The cryptographic statement “QROM adversary can query $H$ in superposition” is often misunderstood as a claim about the endpoints being quantum.

It is not. Endpoints can remain classical.

QROM is a claim about the adversary’s ability to implement the oracle coherently given a public description. Hash functions are public, deterministic circuits. If an attacker has a quantum computer, it can run $H$ as a quantum circuit and query it on a superposition. That is true regardless of whether your server is classical, embedded, or IIoT.

This is why QROM is not optional for long-lived infrastructure. If your security boundary assumes “the attacker cannot evaluate $H$ coherently,” you need to justify that assumption at the system level (rate-limited remote oracles, hardware-enforced classical interfaces, etc.). Otherwise you are not in ROM; you are in QROM by default.

3.1 System constraints that proofs ignore

Formal QROM proofs also assume an idealized interface on the defender side:

• unbiased randomness for keygen and masking,
• constant-time behavior where required,
• memory erasure where ephemerality is assumed,
• and no side-channel observation beyond what the model states.

In PQC implementations, the gap between proof model and deployed system can be larger than in classical ECC/RSA code because state and bandwidth are larger and performance pressure is higher.

4. Core Argument / Insight

QROM does not just make attacks stronger. It invalidates the assumptions behind how we prove security.

If your proof relies on:

• query observability,
• transcript extraction,
• point programming without global entanglement analysis,
• classical rewinding / forking,

then your ROM proof is not evidence of security against quantum-capable adversaries. You need an explicit QROM argument, or you need to explicitly justify that your system boundary makes only classical oracle access relevant.

5. Implications

5.1 PQ signatures: ROM proofs are not the end of the story

Many modern signature schemes (including lattice-based families) are structurally tied to FS-style transforms. Even when standards documents present security arguments, the long-term claim you care about is a QROM claim, not a ROM claim.

This is not panic. It is model hygiene:

A proof in ROM is not evidence of security in a quantum-capable world.

5.2 ZK and blockchain: the Fiat–Shamir heuristic is infrastructure

Most deployed ZK proof systems in blockchains are non-interactive by applying Fiat–Shamir to interactive protocols. If your security story assumes ROM and you deploy into a 10–20 year horizon where quantum adversaries are plausible, you need to understand which parts of your system are actually proven in QROM and which are heuristic.

5.3 Protocol design: treat the oracle interface as a first-class spec object

At the protocol level, the correct engineering move is to define the oracle model explicitly:

• what functions are modeled as random oracles (hash/KDF/transcript),
• what the adversary interface is (classical evaluation vs coherent evaluation),
• what the resource budgets are (query bounds, time, memory, coherence),
• what the system boundary prevents (if anything).

Without that, “post-quantum” becomes a label rather than a claim.

Failure modes

• Treating QROM as “ROM + Grover factor” and carrying ROM proofs forward unchanged.
• Assuming rewinding-based extractors still work because “we can just rerun the adversary.”
• Treating oracle programming as a harmless point change without a QROM reprogramming bound.
• Confusing “adversary is quantum” with “endpoints are quantum,” and therefore under-modeling oracle access.

What to monitor

• Where your stack uses Fiat–Shamir (signatures, transcripts, ZK proofs, aggregations).
• Which proofs are explicitly QROM (and what the tightness/assumptions are) versus “ROM only.”
• Whether the system boundary truly enforces classical oracle access (it usually does not for hash functions).
• Implementation regressions that invalidate model assumptions (randomness bias, timing leakage, memory non-erasure).

Rollback plan

If you deploy primitives/protocols whose story changes materially between ROM and QROM, treat that as an agility requirement:

• version suite IDs explicitly (no aliasing of “equivalent” constructions),
• bind suite choice into transcript authentication,
• keep a deprecation window and telemetry for legacy behavior,
• and pre-plan re-keying / credential rollover paths.

6. Continuity Hook

Part 4 will be about tightness and parameter inflation: how QROM-aware proofs often introduce additional loss factors, how those losses map (or fail to map) into concrete parameter sizing, and why “Category 5” language can hide fragile reductions.

7. References

Evidence

• The formal distinction between ROM and QROM and the oracle interface shift is made explicit in Boneh et al. (1)
• Concrete QROM techniques (recording queries / compressed oracle) are developed by Zhandry. (2)
• The limits and conditions of Fiat–Shamir in QROM are analyzed by Unruh and by Don et al. (3) (4)
• Grover/BBBV quantify the structural query-economics shift that sits underneath many ROM intuitions. (9) (8)
• Watrous gives a canonical example of when quantum rewinding works and when it does not generalize. (7)

Checklist

• For every security claim, state whether it is ROM, QROM, or “quantum computation with classical oracle access.”
• For every FS usage, identify the extraction/simulation proof technique (and whether it is QROM-valid).
• Document query/time/memory/coherence budgets as part of the security target.
• Track proof tightness losses and map them into concrete parameter sizing.
• Treat parameter inflation as a side-channel and ops-risk amplifier.

Further reading

• Boneh et al., “Random Oracles in a Quantum World” (ePrint 2010/428). (1)
• Zhandry, “How to Record Quantum Queries…” (ePrint 2018/276). (2)
• Unruh, “Post-Quantum Security of Fiat-Shamir” (ePrint 2017/398). (3)
• Don–Fehr–Majenz–Schaffner, “Security of the Fiat-Shamir Transformation in the QROM” (ePrint 2019/190). (4)
• Watrous, “Zero-Knowledge Against Quantum Attacks” (SIAM J. Comput., 2009). (7)
• Grover, “A fast quantum mechanical algorithm for database search” (1996). (9)
• BBBV, “Strengths and Weaknesses of Quantum Computing” (1997). (8)

Author: Mayckon Giovani
Date: April 26, 2026
Series: PQC Research Series
Tags: PQC, Formal Methods, Cryptography, Systems

0. Context

Post-quantum cryptography is usually discussed as a migration exercise: replace ECDH with ML-KEM, replace RSA/ECDSA with ML-DSA / SLH-DSA, keep the rest. That framing is operationally convenient and mathematically incomplete.

Underneath the primitives, PQC is a statement about complexity assumptions: not only that certain lattice problems are hard, but that the particular distributions and structures we deploy are hard under the resource model we actually face. That “under” clause is the whole problem.

Reductionist security tends to overfit to the cleanest layer: “scheme $\Rightarrow$ LWE/SIS $\Rightarrow$ worst-case lattice hardness.” Systems security fails one layer earlier: the implementation and the operational environment frequently step outside the model (biased noise, correlated randomness, side-channel traces, non-atomic erasure, misconfigured parameters). If the reduction is a refinement map, those violations are breaking refinement.

1. Problem Statement

Fix a security parameter $\secpar \in \N$. Let $\proto_P$ be a PQC primitive instantiated at a concrete parameter set $P$ (dimensions, modulus, noise distribution, ring/module structure, compression rules, etc).

We would like a statement of the form:

under a hardness assumption $\mathsf{Hard}(P)$ such as LWE or SIS.

In theory, $\mathsf{Hard}(P)$ is defined in an idealized sampling and oracle model. In production, $\proto_P$ is realized by a stateful implementation $I_P$ running under system constraints (entropy sources, memory limits, microarchitectural leakage, concurrency schedules, firmware quirks). The real question is therefore not “is LWE hard?” but:

1. Which exact assumption is the proof actually using? (search-LWE vs decision-LWE, secret distribution, error distribution, structure, number of samples, oracle model). (1) (2)
2. What is the reduction loss and how does it translate to concrete parameters? Non-tightness is not a theoretical footnote; it is a sizing input. (3) (4)
3. Does the implementation preserve the model boundary? If $I_P$ does not sample from $\chi$, leaks timing, reuses randomness, or fails to erase secrets, then “security under LWE” is not even a well-posed claim.

So the formal problem is:

Define a model boundary $\mathcal{B}(P)$ for the deployed primitive, and prove (or at least bound) that the deployed system $(I_P)$ refines the ideal model required by the reduction.

This is the same engineering move you make when you prove a protocol implementation refines a TLA+ spec: you do not get correctness from a spec; you get correctness from a refinement argument that survives the real machine.

2. Formal Model

2.1 Lattices and worst-case problems

A (full-rank) lattice $\Lambda \subset \R^n$ can be represented by a basis matrix $B \in \R^{n \times n}$:

Let $\lambda_1(\Lambda)$ be the length of the shortest non-zero vector in $\Lambda$, and let $\lambda_i(\Lambda)$ denote the $i$-th successive minimum.

Two canonical worst-case approximation problems are:

• $\mathsf{GapSVP}_\gamma$: decide whether $\lambda_1(\Lambda) \le 1$ or $\lambda_1(\Lambda) > \gamma$ for approximation factor $\gamma$.
• $\mathsf{SIVP}_\gamma$: find $n$ linearly independent vectors in $\Lambda$ each of length at most $\gamma \cdot \lambda_n(\Lambda)$.

These are not just academic artifacts; they are the anchor points of worst-case/average-case reductions.

One additional object appears constantly in the LWE/SIS reduction chain: $q$-ary lattices induced by modular linear constraints. Given $A \in \Z_q^{m \times n}$, define:

This is the lattice-theoretic view of “solutions to $Ax=0 \bmod q$,” and it is the bridge between average-case modular samples and worst-case geometric statements.

2.2 Learning With Errors (LWE)

Let $n, m \in \N$, modulus $q \ge 2$, and an error distribution $\chi$ over $\Z$ (typically a discrete Gaussian or a centered bounded distribution). Sample:

and define:

The search-LWE problem is: given $(A,b)$ sampled as above, recover $s$.

The decision-LWE problem is: distinguish $(A, A s + e)$ from uniform $(A, u)$ where $u \gets \Z_q^m$.

Regev’s foundational result (and its refinements) relate average-case LWE to worst-case lattice problems in an explicit parameter regime. A usable engineering summary is:

For $q=\mathrm{poly}(n)$ and noise rate $\alpha$ with $\alpha q \gtrsim \sqrt{n}$, an efficient LWE solver would imply an efficient worst-case lattice solver for $\mathsf{GapSVP}$ / $\mathsf{SIVP}$ at approximation factor roughly $\tilde{O}(n/\alpha)$. (1) (2)

Regev’s original reduction is quantum; later work establishes comparable hardness under classical reductions in relevant regimes. (5)

Two details matter more than people admit:

1. Which distribution is assumed. Proofs typically state $\chi$ as a discrete Gaussian or a distribution with explicit tail bounds. Implementations often use centered binomial or other efficient samplers, which must be justified as “close enough” in the right sense for the specific proof obligations you are relying on. (3)
2. Which LWE flavor is assumed. Search/decision equivalences exist in many regimes, but they are not a magical black box; they can depend on $q$, on the secret distribution, and on how you treat noise. If your implementation deviates (small secret, compressed samples, non-i.i.d. noise), you need to know what you are implicitly assuming.

efficient LWE solvers imply efficient worst-case lattice solvers (for certain approximation factors), under explicit distributional assumptions. (1) (2) (5)

2.3 Short Integer Solution (SIS)

Let $A \gets \Z_q^{m \times n}$. The SIS problem with bound $\beta$ is to find a non-zero vector $x \in \Z^n \setminus \{0\}$ such that:

Equivalently, SIS asks for a short non-zero vector in the $q$-ary lattice $\Lambda_q^\perp(A)$.

SIS is the canonical collision / relation-finding hardness backbone for lattice-based hash functions and commitment-style components. Ajtai’s work is the root of the worst-case/average-case connection here: average-case short relations in random modular constraints imply worst-case hardness in lattice geometry. (6)

2.4 Structured variants: Ring-LWE and Module-LWE

Efficiency demands structure; security pays for it.

Let $R = \Z[x]/(f(x))$ with cyclotomic choices common in practice (e.g., $f(x)=x^N+1$ for power-of-two $N$), and $R_q = R / qR$.

• Ring-LWE samples $A,s,e$ in $R_q$ and defines $b = A s + e$ in the ring. The hardness reductions are to worst-case problems on ideal lattices, which is a narrower and more structured family than arbitrary lattices. (7)
• Module-LWE lives in $R_q^k$ (a module of rank $k$), interpolating between unstructured LWE (large $k$, less structure) and Ring-LWE ($k=1$, maximal structure). This is exactly the reason the NIST standards emphasize “module-lattice-based” constructions: it is the efficiency/security Pareto surface the community has converged on. (8)

The engineering takeaway is not “Ring bad, Module good.” The takeaway is: structure is an attack surface and the reduction story becomes more delicate as structure increases.

Concrete example: the ML-KEM parameter sets standardized in FIPS 203 instantiate a Module-LWE lineage over $R_q$ with $N=256$, $q=3329$, and module ranks $k \in \{2,3,4\}$ (corresponding to ML-KEM-512/768/1024). They do not use an “ideal discrete Gaussian”; they use efficient bounded samplers and explicit compression/rounding rules. Those are engineering choices, and they are part of the assumption surface area. (8)

2.5 Reduction loss and concrete security (why parameters get fat)

Reductions are rarely tight. In schematic form, a typical security proof looks like:

where $c(n)$ is polynomial and $\varepsilon(P)$ collects statistical distance terms, failure probabilities (e.g., decryption failures), and other “small” terms.

In asymptopia, “polynomial” is harmless. In production, $c(n)$ forces you to inflate parameters to recover a desired concrete margin. If you want to reason about bit-security, you need:

1. a reduction (often non-tight),
2. an attack cost model (heuristic),
3. and a mapping from that model to operational budgets (time, memory, parallelism, side-channel surface).

This is where the lattice estimator ecosystem exists: it is not part of the theorem, but it is part of deployment reality. (4) (9)

To make this concrete, the backbone of many classical lattice attacks is BKZ reduction. The quality of a reduced basis is often summarized by the root Hermite factor $\delta_0$ such that (heuristically):

where $\beta$ is the BKZ block size and $\det(\Lambda)$ is the lattice determinant. Under standard heuristics (GSA), a common approximation is:

The deployment-level problem is that $\beta$ is not just a parameter in a paper; it is an attacker knob trading time vs memory vs parallelism, and your “bit-security” estimate is a projection of that multidimensional optimization into a single scalar. That projection is where most engineering overconfidence lives. (4) (9)

flowchart TD
  A["Worst-case lattice hardness (GapSVP/SIVP)"] -->|reduction| B["Average-case assumption (LWE/SIS distribution)"]
  B -->|construction| C["Primitive (KEM / Signature)"]
  C -->|implementation| D["System artifact (CPU + RNG + memory + concurrency)"]
  D -->|observable traces| E["Adversary view"]
  E -->|attack selection| F["Concrete cost model (BKZ / sieving / BKW / hybrids)"]
  F -->|security margin| G["Operational claim ('128-bit', etc.)"]
  D -. breaks .-> B
  D -. breaks .-> C

3. System Constraints

This is the part formal papers cannot carry for you. If you operate in IIoT, distributed control planes, VPN endpoints, or globally deployed backend services, you do not get the “ideal sampler + ideal CPU + ideal leakage” model for free.

3.1 Distribution preservation is a correctness property

Suppose the proof requires error distribution $\chi$ but the implementation samples $\chi'$. Let $\Delta = \mathrm{SD}(\chi,\chi')$ be the statistical distance between the two single-sample distributions.

By a standard hybrid argument, for $m$ independent samples:

This is a hard bound on how much your implementation can drift before you have materially changed the assumed problem distribution.

In other words: sampler bias is not “implementation detail.” It is a parameter in the adversary’s distinguishing advantage.

3.2 Memory and cache behavior are part of the attacker interface

The LWE/SIS hardness games assume the adversary sees algebraic samples, not microarchitectural traces. Real code runs on CPUs that leak via timing, cache, branch predictors, and transient execution. This induces a leakage channel:

and the attacker’s observation is no longer $(A,b)$; it is $(A,b,\mathsf{Leak}(\cdot))$.

You do not get to hand-wave this away by calling it “side-channel hardening.” If leakage depends on secret-dependent control flow or memory access, the problem you are solving is not LWE; it is “LWE with a leakage oracle,” which is a different assumption.

Operationally, this forces concrete constraints:

• constant-time arithmetic for NTT/multiplication paths,
• constant-time sampling and rejection logic,
• no secret-dependent table indices,
• explicit zeroization of ephemeral secrets and intermediate buffers,
• avoiding shared mutable RNG state across concurrent sessions.

3.3 Determinism, concurrency, and entropy budgets

Distributed systems want determinism (reproducible builds, deterministic state machines) and often run in constrained environments (IIoT gateways, embedded devices, enclaves, containers with weak entropy at boot). That collides with lattice schemes in predictable ways:

• Entropy: ML-KEM-style primitives need fresh randomness per encapsulation; “reuse because it’s faster” is a catastrophe. (8)
• Concurrency: shared RNG state across goroutines/threads becomes a correlation gadget.
• Crash consistency: erasure is not atomic; you must treat “crash after keygen but before zeroization” as part of the adversary model.

If you want to be honest, the system boundary must state which of these are assumed and which are enforced.

4. Core Argument / Insight

The deep failure mode in PQC deployments is not that LWE/SIS become easy. The failure mode is that teams confuse:

• a reduction (a conditional implication in an ideal model),
• a parameter choice (a concrete instantiation sized using heuristic cost models),
• an implementation (a program that must preserve distribution and hide secrets),
• and a system (a stateful, concurrent, observable artifact operating under failure).

When those layers are collapsed into “we use lattice crypto, therefore quantum-safe,” the security claim becomes meaningless.

So the right way to think about LWE/SIS in systems engineering is to treat them as assumption interfaces with explicit obligations. A minimal obligation set looks like this:

1. Sampling obligations: error/secret sampling matches the assumed distribution within negligible distance; compression does not introduce exploitable bias; decryption failures are bounded and monitored.
2. Leakage obligations: constant-time boundaries for secrets; avoidance of secret-dependent memory access; hardened error paths.
3. Lifecycle obligations: keys and intermediate secrets are erased promptly; crash behavior does not leave long-lived secrets resident; “ephemeral” is enforced, not asserted.
4. Agility obligations: parameters and algorithms are versioned protocol objects; rollout and rollback are engineered, not improvised.

The reason this matters is that concrete security is not a theorem; it is an adversarial optimization problem.

You can write it as:

where $\text{model}$ encodes time, memory, parallelism, and (increasingly) quantum speedups. The uncomfortable point: $\mathsf{Work}_{\mathsf{alg}}$ is heuristic for the best attacks we know, and it changes over time. (3) (4)

The resulting posture should be adversarial and operational:

• assume estimator drift (new BKZ/sieving improvements),
• assume implementation faults (timing, RNG, error oracles),
• and design rollback paths as if you will need them.

5. Implications

For production systems, treating LWE/SIS correctly implies specific engineering decisions:

1. Treat parameter sets as part of the protocol version. If you cannot unambiguously name $P$ (including compression rules, domain separation, and failure semantics), you cannot reason about interoperability or downgrade surfaces.
2. Make distributional correctness testable. Sampler tests, statistical checks, and CI gates are not “nice-to-have.” They are how you maintain the refinement boundary.
3. Budget for memory-hardness and DoS. Lattice operations are attacker-triggerable (handshakes, key exchanges). Your availability model must treat expensive crypto as an attack surface, especially under packet loss and retries.
4. Formalize lifecycle invariants. “Ephemeral” means erased before the next adversarial event. Specify it like an invariant and enforce it like one.
5. Be explicit about structure. Ring/Module structure buys you performance. It must be treated as an explicit risk trade-off, with monitoring and agility, not as free security.

6. Continuity Hook

Part 1 defined adversary models (classical vs quantum vs QROM) by specifying interfaces and resource vectors. Part 2 defined LWE/SIS as assumption interfaces with concrete system obligations.

The next step is inevitable:

how do lattice hardness and reduction arguments change once the attacker is quantum, and how should we account for quantum time–memory trade-offs (and QROM interfaces) when sizing parameters for real systems?

That is Part 3: quantum cost models, coherence budgets, and what “post-quantum hardness” actually means in operational terms.

7. References

• Regev, “On Lattices, Learning with Errors, Random Linear Codes, and Cryptography” (JACM). (1)
• Ajtai, “Generating Hard Instances of Lattice Problems” (STOC '96). (6)
• Micciancio & Regev, “Worst-Case to Average-Case Reductions Based on Gaussian Measures” (SIAM J. Comput.). (2)
• Brakerski et al., “Classical Hardness of Learning with Errors” (STOC '13). (5)
• Lyubashevsky, Peikert & Regev, “On Ideal Lattices and Learning with Errors over Rings” (EUROCRYPT 2010). (7)
• Chen & Nguyen, “BKZ 2.0: Better Lattice Security Estimates” (ASIACRYPT 2011). (4)
• Peikert, “A Decade of Lattice Cryptography” (FnT TCS). (3)
• NIST, “FIPS 203: ML-KEM” (CSRC). (8)
• Albrecht et al., “LWE estimator” (GitHub). (9)

Author: Mayckon Giovani
Date: April 24, 2026
Series: PQC Research Series
Tags: PQC, Formal Methods, Cryptography, Systems

0. Context

This article formalizes the adversary models that actually sit underneath “post-quantum security” claims.

Most production discussions about PQC are framed as a primitive replacement problem: swap an ECDH group for an ML-KEM parameter set; swap RSA/ECDSA for ML-DSA or SLH-DSA; keep the rest unchanged.

That framing is incomplete. A security statement is only meaningful relative to a threat model that specifies:

• what computation model the attacker runs (classical PPT vs quantum polynomial-time),
• what interfaces the attacker has (classical vs quantum/superposition oracle access),
• what resources are bounded (time, memory, and query budgets),
• and what the system boundary is (what is and is not coherently queryable, what leaks, what must be erased).

Post-quantum migration fails silently when these are left implicit. This is not philosophical; it is a specification error. In particular, the Quantum Random Oracle Model (QROM) is not “ROM but stronger.” It is a different oracle interface and forces different proof techniques, different failure modes, and different deployment assumptions. (1)

1. Problem Statement

Let $\lambda \in \mathbb{N}$ be a security parameter. A cryptographic system $\Pi$ is a set of algorithms and stateful components composed into a protocol:

We want a threat model that supports machine-checkable security claims of the form:

where:

• $\mathcal{M}$ is the oracle model / interface regime (e.g., ROM vs QROM),
• $A$ is an adversary whose capabilities belong to an admissible class $\mathcal{C}(\lambda)$,
• $\mathrm{Adv}$ is the advantage of $A$ in some security game (IND-CCA, EUF-CMA, AKE, etc),
• and $\mathcal{C}(\lambda)$ encodes explicit resource bounds.

The core modeling problem is to define $\mathcal{C}(\lambda)$ such that it captures the operational adversary we must assume in PQC deployments:

1. Classical adversaries (probabilistic polynomial-time, classical oracle access).
2. Quantum adversaries with classical oracle access (quantum computation, but the environment only answers classical queries).
3. Quantum adversaries with quantum oracle access (superposition queries), which induces QROM-style analysis.

Then we must define a resource vector that is explicit enough to be operationally relevant:

where $T$ is time, $M_c$ is classical memory, $M_q$ is quantum memory (qubits), $q_H^c$ and $q_H^q$ are classical vs quantum queries to a hash/oracle $H$, and $\mathcal{O}$ is the set of other interfaces (e.g., signing oracle, decapsulation oracle, network endpoints).

The reason to insist on this vector is that PQC security often collapses into “it’s 128-bit” language without any statement about what costs 128-bit under quantum constraints, and which part of the system gives the attacker those costs.

2. Formal Model

2.1 Notation and conventions

• $\lambda$ is the security parameter.
• $\ell(\lambda)$ is an output length (typically $\ell(\lambda)=\lambda$ or $\ell(\lambda)=2\lambda$).
• $H: \{0,1\}^{\ast}\rightarrow \{0,1\}^{\ell(\lambda)}$ denotes a random oracle.
• $\mathrm{negl}(\lambda)$ denotes a negligible function.
• “PPT” is probabilistic polynomial-time.
• “QPT” is quantum polynomial-time (uniform family of poly-size quantum circuits).

I will write security games in the standard game-based style: the challenger samples secrets, exposes oracles, the adversary outputs a bit, and advantage is the distinguishing gap.

2.2 Classical adversary (PPT + classical oracle access)

A classical adversary $A$ is a PPT algorithm. In the ROM, $A$ can query the random oracle $H$ on classical inputs:

Formally, $A$ is an oracle algorithm $A^{H,\mathcal{O}}(1^\lambda)$ that can make at most $q_H^c(\lambda)$ classical queries to $H$ and at most $q_O(\lambda)$ classical queries to each oracle $O\in\mathcal{O}$, running in time $T(\lambda)$.

The ROM proof toolbox relies on:

• lazy sampling (define $H(x)$ on first query),
• programming (set $H(x^\star)$ to a chosen value),
• and transcript extraction via recorded queries.

These are not generic moves in the quantum setting.

2.3 Quantum adversary (QPT) with classical oracle access

The first quantum strengthening is computational, not interface.

Let $A_Q$ be a QPT adversary. Concretely, for each $\lambda$, $A_Q$ is a quantum circuit $C_\lambda$ with polynomially many gates, acting on a polynomial number of qubits, with access to classical oracles.

In this model, $A_Q$ can run quantum algorithms (Shor, Grover, quantum walks, etc.) but can only query the oracle $H$ by measuring an input $x$ and receiving a classical output $H(x)$. This is a meaningful model for certain deployments where an oracle is only accessible through an inherently classical interface (e.g., rate-limited remote services that do not provide coherent access).

However, it is not a safe default for hash functions, because a public hash function is not a remote service: it is an algorithm. If its description is public, a quantum adversary can implement it coherently. That is why QROM exists.

2.4 Quantum adversary with quantum oracle access (QROM)

In QROM, the random oracle is not an abstract lookup table that returns values. It is a unitary transformation that can be queried on superpositions of inputs. (1) (2)

Fix an output length $\ell(\lambda)$. Let $H$ be sampled uniformly at random from all functions $\{0,1\}^{n}\rightarrow \{0,1\}^{\ell(\lambda)}$ for some fixed input length $n$ (or use a prefix-free encoding to reduce variable-length inputs to fixed-length blocks).

Define the oracle unitary:

where $\oplus$ is bitwise XOR in $\{0,1\}^{\ell(\lambda)}$ (and $|y\rangle$ is an $\ell(\lambda)$-qubit register).

A QROM adversary $A_Q$ is allowed to interleave its own unitaries $U_1,\dots,U_k$ with calls to $U_H$:

for at most $q_H^q(\lambda)$ oracle calls. The final measurement produces the adversary’s output.

This single change (from classical query to coherent oracle access) breaks the ROM reduction move “record all random oracle queries and reprogram one point,” because:

• there is no classical transcript of queries (queries are quantum states),
• measuring the query register disturbs the adversary’s state,
• and the adversary can query many points at once in a superposition state.

This is not a nuisance detail. It is a structural change in what “knowing $H(x)$” means.

2.5 Resource accounting: queries, memory, time

The statement “secure against quantum adversaries” is incomplete until we pin down the resource regime.

In practice, we need a resource accounting that is explicit enough to:

1. map to parameter choices,
2. map to operational constraints (HSM/IIoT/embedded),
3. survive protocol composition.

I use the following canonical resource vector:

Interpretations:

• $T$ (time) is gate complexity: the number of elementary quantum gates in the circuit description of $A$ (or a conservative upper bound).
• $M_q$ is the maximum number of qubits kept coherent at any time (quantum workspace + oracle query registers).
• $M_c$ is classical memory (bits or words) used by $A$.
• $q_H^q$ is the number of quantum oracle calls to $U_H$.
• $q_H^c$ is the number of classical evaluations of $H$ (which a quantum adversary can simulate by measuring its input register and computing).
• other $q_O$ correspond to protocol or hardware interfaces (e.g., a signing oracle can represent a compromised signing service; a decapsulation oracle can model error-oracle exposure; a network oracle can model active MitM capability).

This matters because quantum attacks are often query-bounded.

For example, for brute-force search in an unstructured space of size $N=2^k$, Grover’s algorithm achieves $O(\sqrt{N})$ oracle queries and is optimal up to constant factors. (3) (4)

Thus, when a system claims “$k$-bit security,” the model must specify what oracle is being queried and how the query complexity maps to the system’s real interface.

2.5.1 Adversary classes as explicit sets

Define the admissible adversary classes as sets parameterized by $\lambda$ and by a budget vector $B$:

Then:

and, crucially,

where $A$ is explicitly allowed to invoke $U_H$ coherently.

This is the right shape for engineering because it makes the theorem boundary a function of explicit parameters:

If you cannot state $B$, you do not have a security target; you have a slogan.

2.6 A concrete game: QROM-EUF-CMA for Fiat–Shamir signatures

It is useful to anchor the model in a game where the ROM/QROM difference is not cosmetic.

Consider a Fiat–Shamir-style signature scheme $\Sigma_{\textsf{FS}}$ constructed from a $\Sigma$-protocol with hash $H$ providing the challenge.