CVE-2026-7734: Dilithium Side-Channel [Deep Dive]

Post-quantum signatures are supposed to survive quantum computers, but they still have to survive physics. That is the practical lesson behind the reporting cluster now being discussed as CVE-2026-7734: a side-channel issue around Dilithium, now standardized by NIST as ML-DSA in FIPS 204. One important caveat comes first: as of April 30, 2026, I could not confirm a public MITRE or NVD record for that exact CVE ID. What is public, however, is a strong body of research showing that poorly hardened Dilithium implementations can leak enough information to recover signing secrets.

CVE Summary Card

• Public status on April 30, 2026: no publicly visible MITRE/NVD entry for CVE-2026-7734 could be confirmed.
• Affected area: implementations of Dilithium / ML-DSA, especially signing code paths.
• Attack class: side-channel leakage, typically power, EM, timing, cache, or secret-dependent memory/control-flow patterns.
• Primary impact: partial or full recovery of private signing material, enabling signature forgery or signer cloning.
• What is not implied: the lattice assumptions behind ML-DSA are not the thing being broken here.
• Why teams should care: standards conformance alone does not make a signer side-channel resistant.

The official and semi-official sources matter here. NIST's FIPS 204 standardizes ML-DSA, but it does not magically harden every real-world implementation. NIST has also highlighted side-channel research on Dilithium in presentations such as Single-Trace Side-Channel Attacks on CRYSTALS-Dilithium: Myth or Reality? and Leveling Dilithium against Leakage. The published evidence is enough to justify urgent engineering attention even before a clean CVE record exists.

Vulnerable Code Anatomy

The critical distinction is between the scheme and the implementation. Dilithium was designed to be friendlier to constant-time coding than schemes that depend on delicate Gaussian sampling. The round-3 specification explicitly frames that as a design goal. But friendlier does not mean leak-proof.

Where leakage tends to appear

• Secret key unpacking: converting compact secret representations into coefficient arrays can create data-dependent load and branch patterns.
• NTT and polynomial arithmetic: intermediate values, especially in hardware or SIMD-heavy code, can correlate with secrets.
• Rejection and hint logic: if implemented carelessly, retries, bounds checks, or normalization steps can reveal structure.
• Deterministic signing paths: repeatable behavior can make repeated measurements easier to align and compare.
• Shared-host deployment: cache behavior, branch prediction, and noisy co-tenancy can still leak useful signal.

Conceptually, the dangerous pattern looks like this:

/* Conceptual example only: illustrates secret-dependent behavior */
for (i = 0; i < N; i++) {
  coeff = unpack_secret(sk_bytes, i);

  if (coeff < 0) {
    table = neg_table;
  } else {
    table = pos_table;
  }

  acc += table[abs(coeff)];
}

The problem is not the syntax. The problem is the behavior. A secret-dependent branch chooses different tables; a lookup touches different memory; power draw and timing shift slightly; and a patient attacker aggregates enough traces to turn those shifts into information.

This is why mature implementations bias toward constant-time unpacking, fixed access patterns, and masking. It is also why the current pq-crystals reference repository should be treated as a reference for correctness and interoperability, not as a universal assurance of side-channel safety on every target.

Attack Timeline

The public record around Dilithium side channels predates any visible 2026 CVE write-up. The dates matter because they show this was not a surprise issue that appeared out of nowhere.

• November 29, 2022: NIST hosted Leveling Dilithium against Leakage, focusing on DPA, SPA, masking gadgets, shuffling, and the trade-off between deterministic and randomized signing.
• October 18, 2022 / PQCrypto 2023 publication cycle: Breaking and Protecting the Crystal reported practical attacks on hardware implementations, including 700,000 profiling traces for an SPA stage, coefficient-pair identification with 1,101 traces after profiling, and CPA recovery with as few as 66,000 traces.
• June 3, 2024: SpringerOpen published In-depth Correlation Power Analysis Attacks on a Hardware Implementation of CRYSTALS-Dilithium, reporting partial private-key recovery with a minimum of 70,000 traces and improvements over baseline CPA.
• April 10, 2024: NIST featured Single-Trace Side-Channel Attacks on CRYSTALS-Dilithium, describing recovery of s1 and s2 coefficients from the secret-key unpacking procedure, with a reported 9% success probability for full s1 recovery from a single trace in one variant and near-100% success when multiple traces are available.
• August 13, 2024: NIST finalized FIPS 204, standardizing Dilithium as ML-DSA.
• February 23, 2026: NIST added an errata planning note to FIPS 204. The note references several minor issues to be corrected in a future revision; it does not by itself establish a side-channel fix.
• April 30, 2026: discussion of CVE-2026-7734 exists in secondary channels, but no public MITRE/NVD entry was visible at the time of writing.

The broader lesson is straightforward: the implementation risk was well telegraphed by the research community before enterprises began large-scale ML-DSA rollout.

Exploitation Walkthrough

This section stays conceptual on purpose. The interesting part is not a toy proof of concept; it is the path from tiny leakage to real signer compromise.

How the attack unfolds

1. Choose a measurement point. The attacker targets a signing operation on a device they can physically probe, a dev board they control, or a shared environment with enough observability to extract timing or cache features.
2. Collect traces. Each signature creates a trace: power samples, EM emissions, cache events, or high-resolution timing signals aligned to a signing routine.
3. Align on a leaky stage. Published work repeatedly points at secret key unpacking, NTT stages, and polynomial operations as fruitful windows.
4. Infer partial secret structure. Using CPA, SPA, or profiled ML methods, the attacker recovers coefficient guesses or sign information for portions of s1 and s2.
5. Complete the key. Public-key relations such as t = A s1 + s2, plus known bits or lattice-reduction techniques described in published work, can fill in what direct leakage did not expose.
6. Clone the signer. Once enough secret material is known, the attacker can generate signatures that verify as if they came from the victim system.

Notice what never happens: the attacker does not solve the underlying lattice problem head-on. They bypass it by learning the private state from the implementation itself. That is why side channels are so operationally dangerous. They turn an advanced cryptosystem back into an ordinary key-extraction problem.

In practical incident response, the blast radius can be larger than one compromised process:

• A leaked software signer can invalidate a code-signing trust chain.
• A compromised device attestation key can make counterfeit hardware look legitimate.
• A side-channel-exposed HSM integration can quietly undercut an otherwise compliant PQC migration plan.

Hardening Guide

If your organization is piloting ML-DSA, the correct response is not panic and not dismissal. It is disciplined hardening.

Engineering controls that matter most

• Eliminate secret-dependent branches and lookups. Audit unpacking, normalization, and arithmetic helpers for data-dependent control flow and memory access.
• Prefer masked and shuffled implementations. The 2022 NIST presentation explicitly centers masking conversions and shuffling as practical countermeasures.
• Use randomized signing where the threat model justifies it. NIST-presented work notes that the randomized version of Dilithium can be more efficient than deterministic signing when side-channel protection is a concern.
• Isolate signing services. Move signing off multi-tenant app nodes and into dedicated hardware or tightly controlled signer processes with reduced observability.
• Limit trace collection opportunities. Rate-limit signing, gate test endpoints, and keep debug interfaces, high-resolution timers, and performance counters out of production.
• Test for leakage, not just correctness. Passing KATs and interoperability tests does not say anything useful about power or EM leakage.
• Protect diagnostic data. If you share traces, logs, or support bundles during vendor triage, scrub them first with tools such as TechBytes' Data Masking Tool.

What a mature hardening workflow looks like

1. Baseline the signer on real target hardware
2. Run constant-time and memory-access audits
3. Capture side-channel traces in a lab setup
4. Add masking/shuffling or swap to a hardened backend
5. Re-test leakage after every optimization pass
6. Gate releases on both crypto correctness and leakage thresholds

One more discipline point: do not oversell “FIPS-compliant” as equivalent to “side-channel hardened.” Those are different claims, and your customers will care about the second one the first time a signing appliance leaks.

Architectural Lessons

The deepest lesson from the Dilithium side-channel story is that post-quantum migration is an architecture problem, not a library swap. Teams that succeed will be the ones that redesign trust boundaries around signing.

What this incident class teaches

• Cryptographic strength and implementation strength are separate budgets. You can have excellent asymptotic security and poor physical security at the same time.
• Signature systems are high-value physical targets. A key encapsulation failure may expose a session; a signature failure can poison software supply chains, firmware trust, and identity roots.
• Reference code is not a deployment blueprint. Research-grade or interoperability-focused code often needs another hardening pass before production use.
• PQC expands the secure-coding surface. New arithmetic kernels, packing formats, and vectorized paths create new places for leakage to emerge.
• Observability can become an attack primitive. The same debug hooks, counters, and profiling tools that help performance teams can simplify side-channel work for attackers.

That makes governance as important as code. Security reviews for ML-DSA should ask not only which algorithm was chosen, but also where signing happens, who can observe it, what traces can be collected, how updates are validated, and whether the implementation was ever evaluated on the actual deployment hardware.

For further reading, start with FIPS 204, the NIST 2024 single-trace presentation, the NIST 2022 leakage presentation, IACR ePrint 2022/1410, and the 2024 SpringerOpen hardware CPA paper. If a public record for CVE-2026-7734 appears later, the safest assumption is that it will describe one concrete implementation failure inside this already well-established attack class.