1. This result constrains your post-quantum cryptography research by demonstrating that compiler-generated register-spilling in ARM Cortex-M4 implementations creates a exploitable side-channel vulnerability in sparse-vector manipulations, which must be mitigated if applying similar code-based structures.

Computer ScienceAug 3, 2026Evaluation Score: 74%

Adversarial Debate Score

57% survival rate under critique

Expert panel critique

Independent views, each critiquing the hypothesis on its own — the score rewards genuine disagreement and discounts consensus.

Gemini: **Strengths:** The hypothesis is highly credible and directly supported by the literature, specifically the paper *"Exploiting Load/Store Leakage of Sparse Vectors for Key Recovery in HQC,"* which confirms that memory operations on sparse secret vectors create exploitable side channels. While the...

Mistral: The hypothesis is falsifiable and partially supported by relevant literature on side-channel vulnerabilities in post-quantum cryptography, particularly sparse-vector manipulations. However, it lacks direct validation from the owner’s own experiments, which focus on unrelated precision/quantizatio...

Claude: The hypothesis has a legitimate empirical anchor in the cited HQC load/store leakage paper, which directly demonstrates side-channel exploitation of sparse-vector manipulations on ARM Cortex-M4 via compiler-generated memory operations; however, the owner's validated experiments are entirely confi...

ChatGPT: The HQC load/store-leakage paper directly supports an exploitable side channel in sparse-vector manipulation, but the excerpts do not independently establish that compiler-generated register spilling on Cortex-M4 is the causal mechanism. The owner’s validated experiments are unrelated, and the br...

Supporting Research Papers

Structural Dependency Analysis for Masked NTT Hardware: Scalable Pre-Silicon Verification of Post-Quantum Cryptographic Accelerators
Post-quantum cryptographic accelerators require side-channel resistance evidence for FIPS 140-3 certification. However, exact masking-verification tools scale only to gadgets of a few thousand cells. ...
Exploiting Load/Store Leakage of Sparse Vectors for Key Recovery in HQC
Hamming Quasi-Cyclic (HQC) is a code-based key encapsulation mechanism selected by NIST for standardization, making its resistance to implementation attacks critically important. We present a side-cha...
Vogls: a Fast Interactive Full-timing Simulator for Pre-silicon Power Side-Channel Analysis
Designing hardware circuits resistant to side-channel attacks increasingly relies on simulation to predict device leakage before fabrication. Current functional verification simulators are designed fo...
The 1-Bit Barrier is Universal: k-Stage Pipeline Composition and Unified Leakage Bounds for Standard Modular Reductions in PQC Hardware
This is Paper 7 of a series of formally-verified analyses of masked NTT hardware for post-quantum cryptography; Paper 1 [1] established structural dependency analysis of the QANARY platform, and Paper...

Formal Verification

Z3 logical consistency:✅ Consistent

Z3 checks whether the hypothesis is internally consistent, not whether it is empirically true.

Experimental Validation Package

This discovery has a Claude-generated validation package with a full experimental design.

Precise Hypothesis

On ARM Cortex-M4 (Armv7E-M, e.g., STM32F4-series) reference and optimized implementations of code-based post-quantum cryptosystems (e.g., Classic McEliece, HQC, BIKE) that perform sparse-vector manipulations (constant-weight vector generation, sparse polynomial multiplication, error-vector sampling), compiler-generated register spilling (observed with GCC/Clang at -O2/-O3 and LTO settings) produces data-dependent memory-access or timing patterns on the spill/fill instructions (LDR/STR/PUSH/VPUSH sequences) whose latency or power trace is statistically correlated (Welch's t-test |t| > 4.5 at ≥ 10,000 traces, or Pearson |r| > 0.3) with secret sparse-vector support positions or Hamming weight, and this correlation is exploitable to recover ≥50% of secret support-index bits using ≤100,000 power/EM traces with a template or CPA attack.

Disproof criteria:

No statistically significant leakage detected (Welch t-test |t| ≤ 4.5 at 100,000 traces, TVLA-style fixed-vs-random test) in spill/fill instruction windows across ≥3 independent compiler configurations.
Key/support recovery rate indistinguishable from random guessing (≤ chance level + 2σ) using CPA/template attacks with up to 200,000 traces.
Leakage present but does not localize to compiler-inserted spill code (i.e., leakage attributable instead to algorithmic branches or memory-access patterns unrelated to register allocation) — this would falsify the causal compiler-spilling claim specifically.
Reproducing the same source code with register-pressure-reducing refactoring (manual variable reduction) eliminates the leakage entirely, supporting the causal link; failure to eliminate it disproves the spill-specific mechanism.

Spine & Adversarial Read

highLeakage attributed to 'register spilling' may actually be confounded with ordinary secret-dependent memory-access patterns already known in code-based PQC (e.g., non-constant-time array indexing), making the 'compiler spilling' framing a relabeling of a known vulnerability class rather than a new finding.
Protocol step 8 (refactor to eliminate spills while preserving identical algorithmic memory-access pattern) is designed to isolate this, but success depends on being able to refactor without changing any other side-channel-relevant characteristic — this is difficult to guarantee in practice and the EVP does not yet include a formal control for 'spill-only' isolation (e.g., via inline assembly diffing to confirm only spill/fill instructions changed).
mediumWhy Cortex-M4 and power/EM side channels specifically, rather than cache-timing or Cortex-M33/RISC-V embedded targets which are increasingly relevant to PQC deployment? The methodology choice is not justified against alternatives.
Cortex-M4 is justified as the de facto pqm4 benchmarking standard (widest prior-art base, no cache making analysis cleaner), but the EVP does not justify exclusion of Cortex-M33 (TrustZone-relevant) or RISC-V targets, which are increasingly deployment-relevant; this narrows generalizability claims and should be stated explicitly as a scope limitation rather than left implicit.
medium100,000 traces and a single t > 4.5 threshold is a relatively low bar compared to modern TVLA practice (often requiring higher trace counts and multiple independent leakage assessment methodologies, e.g., non-specific + specific TVLA, mutual information analysis) — the success criteria may be too permissive to be publication-grade.
Trace count and threshold are aligned with common embedded side-channel literature conventions but the EVP should add a secondary confirmatory test (e.g., non-specific TVLA plus a held-out validation set) before treating a single t-test pass as conclusive; this is not currently specified and is a real gap.

Experimental Protocol

Minimum viable test (MVT): Implement a reduced sparse-vector kernel (e.g., constant-weight vector generation from HQC or Classic McEliece reference code) on an STM32F4 Discovery board. Compile at -O0 (baseline, no spill) and -O3 (spill-inducing) with GCC. Capture 20,000 power traces per configuration using ChipWhisperer or a shunt-resistor+PicoScope setup while varying secret support index inputs. Run Welch's t-test (fixed-vs-random TVLA) and correlation power analysis (CPA) targeting the spill/fill instruction window. Compare leakage magnitude and key-recovery success rate between -O0 and -O3 builds; disassemble to confirm spill instructions are present via objdump.

Required datasets:

Reference source code: liboqs / pqm4 implementations of Classic McEliece, HQC, BIKE (sparse-vector routines).
Hardware: STM32F407 Discovery or NUCLEO-F411RE board, ChipWhisperer-Lite/Pro CW308 UFO target board.
Measurement equipment: oscilloscope (≥500 MS/s, e.g., PicoScope 5000 series), EM near-field probe kit (Langer ICR HH or similar), shunt resistor (10–50 Ω) if using power capture.
Toolchain: arm-none-eabi-gcc (10.x, 12.x, 13.x), Clang/LLVM (14–17), objdump/readelf for disassembly verification.
Software: ChipWhisperer Capture/Analyzer, custom CPA/TVLA scripts (Python, NumPy, SciPy, scared or eshard's own leakage-assessment library).
Trace dataset: minimum 100,000 traces per (compiler, opt-level) configuration for adequate statistical power; store as HDF5.

Success:

TVLA |t| > 4.5 sustained over ≥5 consecutive samples localized to disassembly-confirmed spill/fill instructions, reproducible in ≥2 of 3 compiler configurations tested.
CPA/template attack recovers ≥50% of secret support-index bits at ≤100,000 traces, significantly above chance (binomial p < 0.001).
Leakage disappears (t-test drops below threshold) after register-pressure-reducing refactor, confirming causal attribution to spilling (not incidental algorithmic leakage).
Effect reproducible across ≥2 independent board samples (controlling for board-specific noise).

Failure:

No TVLA leakage above threshold in any spill-instruction window across all tested configurations at 100,000+ traces.
Leakage present but persists identically after refactor removing spills (indicating non-causal/confounded source).
Key recovery rate statistically indistinguishable from chance (within 2σ) even at 200,000 traces.
Effect not reproducible across compiler versions (i.e., artifact of one specific toolchain build, undermining generality claim).

ROI Projection

Implementation Sketch

for scheme in [ClassicMcEliece_ConstWeight, HQC_ErrVecSample]:
  for compiler in [gcc-10, gcc-13, clang-16]:
    for opt in [-O0, -O2, -O3]:
      binary = compile(scheme.src, compiler, opt)
      spill_count = objdump_count_spills(binary)
      flash(binary, target=STM32F407)
      traces = []
      for trial in range(100_000):
        secret = sample_input(mode='fixed_vs_random')
        trace = capture_power_or_EM(trigger_gpio, secret)
        traces.append((trace, secret))
      leak_result = TVLA_ttest(traces)
      window = localize_to_disassembly(leak_result, binary)
      cpa_result = CPA_attack(traces, leakage_model='HW', target_window=window)
      log(scheme, compiler, opt, spill_count, leak_result, cpa_result)
  refactored = reduce_register_pressure(scheme.src)
  repeat_capture_and_analyze(refactored)  # causal confirmation

Abort checkpoints:

Checkpoint 1 (Day 10): If disassembly shows no spill instructions generated at -O3 for chosen kernels (register pressure insufficient) — must redesign kernel with higher live-variable count before proceeding.
Checkpoint 2 (Day 20): If TVLA shows no leakage above noise floor at 20,000 traces on first configuration — escalate trace count to 50,000 before full 100,000-trace run; if still null, consider probe/setup fault before concluding null result.
Checkpoint 3 (Day 30): If leakage found but CPA fails to recover any bits above chance at 100,000 traces — reassess leakage model (switch HW to HD model) before abort.
Checkpoint 4 (Day 38): If refactor fails to eliminate leakage — pause and re-verify refactor actually eliminated spills via disassembly before concluding non-causal result.

NAMED_EXPERTS: []

CLOSEST_EXISTING_WORK: []

NOVELTY_NARROWING_REQUIRED: false

SPINE_STATEMENT: This hypothesis tests whether compiler-generated register spilling in -O2/-O3-compiled ARM Cortex-M4 implementations of code-based post-quantum sparse-vector operations produces a statistically exploitable power/EM side channel that recovers secret support-index information.

Source

AegisMind Research

Need AI to work rigorously on your problems? AegisMind uses the same multi-model engine for personal and professional use. Get started