Nonce@Once: Exploiting Nonce Misuse

Updated 15 December 2025

Nonce@Once is a class of vulnerabilities that arise when nonces, meant to be unique and unpredictable, are reused or algebraically related across operations.
It enables attackers to compromise cryptographic schemes like ECDSA, bypass web security via CSP nonce reuse, and perform pre-play attacks in payment protocols.
Mitigations include secure nonce generation, strict enforcement of one-time use through static type systems, and robust randomness in security-critical implementations.

The Nonce@Once attack describes a broad class of cryptanalytic and security-breaking strategies that exploit failures in nonce (number used once) management across a range of protocols and implementation settings. At its core, the attack targets scenarios where a nonce—whose security function is guaranteed only by its uniqueness and unpredictability within a session or usage—can instead be reused, partially predicted, or linearly related across instantiations. Such failures convert nonces from hard privacy or integrity barriers into vectors for one-shot attacks: a single instance of nonce misuse can suffice for full secret-key or authentication compromise. The Nonce@Once paradigm has emerged as a unifying conceptual thread for vulnerabilities in cryptographic signatures (especially ECDSA), web security policies (notably CSP nonces), EMV payment protocols, AEAD ciphers, and black-box adversarial machine learning contexts.

1. Conceptual Foundations of the Nonce@Once Attack

In contemporary cryptography and protocol security, nonces enforce freshness, uniqueness, and resistance to replay. Protocols typically assume that a nonce is used for a single operation, is unpredictable before use, and never reappears elsewhere within a security domain. The Nonce@Once attack leverages any violation of these properties—reuse, prediction, or algebraic linkage among nonces—to render the cryptographic construction vulnerable.

Crucially, Nonce@Once is not limited to mere value reuse; it encompasses attacks based on affine (or more general) relationships, information leakages (as in side channels), and practical misconfigurations leading to nonces being predictable or shared. This attack class has direct implications for signature forgeries, authentication bypasses, message forgeries under AEAD, cross-site scripting (XSS) escalations, and pre-play attacks in payments.

2. Affine and Reused Nonces in Cryptographic Protocols

A central manifestation of Nonce@Once is in digital signatures, notably ECDSA. The protocol depends critically on the uniqueness and secrecy of the nonce $k$ : the signature $s = k^{-1}(h(M) + d\,r)\bmod q$ binds the nonce $k$ , message hash $h(M)$ , public value $r$ , and the private key $d$ . Nonce reuse ( $k_1 = k_2$ ) across distinct signatures allows immediate key recovery via linear equations. The Nonce@Once attack class subsumes this, but also includes the scenario in which nonces are affinely related: $k_1 = a\,k_2 + b \pmod q$ with known $a,b$ .

The attack proceeds by algebraically manipulating observed signature pairs:

$d \equiv \frac{a\,s_1\,h_2 + b\,s_1\,s_2 - h_1\,s_2}{r_1\,s_2 - a\,s_1\,r_2} \pmod q,$

demonstrating that as long as the affine relation is predictable, a single nonce "link" suffices for key compromise from two signature transcripts, even for signatures on the same message. This extends previous knowledge, which considered only exact duplicate nonces as dangerous, to any algebraic relation that an adversary can exploit (Gilchrist et al., 18 Apr 2025).

Side-channel vectors further amplify this risk; electromagnetic (EM) emanations can leak bits of $k$ in constant-time ECDSA implementations. Even a single EM trace can suffice (in the worst case) to reconstruct all nonce bits, and hence the private key, yielding a quintessential "Nonce@Once" compromise (Oberhansl et al., 8 Dec 2025).

3. Web Security: CSP Nonce Reuse and XSS Bypass

CSP (Content Security Policy) nonces protect against script injection by requiring each inline script to carry a server-issued, unpredictable 'nonce-N', which browsers verify matches the HTTP header's declared nonce before execution. Intent is that every value of N is freshly generated per response.

Empirical studies reveal that a significant proportion of web sites (26.3% of nonce-using CSP deployments) reuse the same nonce value across multiple responses, due to application misconfiguration or caching (Golinelli et al., 2023). This enables a trivial Nonce@Once attack: an attacker retrieves the reusable nonce (N), injects a malicious script with that nonce via a reflected XSS vulnerability, and on victim visit, the browser executes the attacker's inline script, circumventing CSP. Reconnaissance needs only a single page fetch; execution proceeds as soon as the attacker can inject a matching script.

Failures are further classified as server-side (persistently emitting the same nonce) or cache-induced (caching dynamic pages with embedded nonces). The exploit has same-session and cross-session variants depending on whether nonces are shared among users.

4. EMV, Payment Protocols, and Pre-Play Attack

In EMV ("Chip and PIN") card transactions, the terminal supplies a 32-bit unpredictable number (UN) intended to act as a nonce for each transaction. Security requires the nonces be fresh and unpredictable; however, many deployed terminals instantiate UN as a counter, timestamp, or weak PRNG. The "pre-play" attack (Nonce@Once in the EMV context) allows adversaries to collect MACs for predicted future UNs from a target card, then later replay them at terminals whose UN generation is predictable.

The steps involve profiling the RNG, harvesting ARQCs for a set of anticipated UNs, waiting for a terminal to emit a matching UN, and replaying the corresponding MAC to authorize fraudulent transactions. When the entropy of the UN source is low, the attack's probability of success increases dramatically (Bond et al., 2012).

5. Static Type Enforcement of Unique Nonce Use

From a language-theoretic perspective, Nonce@Once attacks can be blocked by enforcing linear (affine) usage of nonce tokens in the type system. By introducing a linear type Nonce and ensuring that every nonce can be consumed exactly once, accidental reuse—even at the code level—is ruled out by construction. In languages such as Rust, this is achieved by requiring that Nonce does not implement Copy and is consumed by cryptographic operations, so that any attempt to reuse the same nonce fails to type-check. This technique provides a compile-time guarantee of nonce uniqueness, closing off whole classes of accidental Nonce@Once vulnerabilities (Ostertág, 2023).

The key theorem states that no well-typed program can ever use the same nonce in more than one operation, preventing both accidental and malicious nonce duplication.

6. Universal Adversarial ML Attacks with Single Queries

Nonce@Once analogues emerge outside traditional cryptography, notably in black-box machine learning attacks. In the "You Only Query Once" (YOQO) setting, the adversary is restricted to querying each image only once—no repeated, near-duplicate queries for gradient estimation. Nonetheless, the attacker can craft a universal perturbation that will mislead most inputs of the classifier.

The attack maximizes average classifier loss via evolution strategies or stochastic finite difference optimization over a dataset, querying each input at most once. This fools existing defenses that rely on repeated-query detection. Empirically, the YOQO attack achieves 67.5% untargeted fooling rate on ImageNet with $q=1$ (one query per image), and up to 20.6% targeted attack success, demonstrating that even under strict nonce-like usage constraints, practical attacks remain feasible (Willmott et al., 2021).

7. Mitigations and Best Practices

Across all domains, the only systematic prevention is to enforce nonce secrecy, unpredictability, and strict one-time use at all system levels:

Cryptographic implementations must use cryptographically secure pseudorandom generators or deterministic per-message procedures for nonce production; any affine or correlated relationship is as damaging as outright reuse (Gilchrist et al., 18 Apr 2025).
For web security, every response must generate a fresh CSP nonce; caching and server logic must guarantee per-request uniqueness and no cross-session leakage (Golinelli et al., 2023).
Hardware and software stacks for payments must enforce both unpredictability and sufficient entropy in nonce sources, with post-audit trail for every incident (Bond et al., 2012).
Static type systems and API wrappers can enforce linear nonce consumption at the code level (Ostertág, 2023).
In adversarial ML, new query-limiting or cross-input statistical defenses are required, as detection mechanisms based solely on repeated queries will fail against Nonce@Once-style attacks (Willmott et al., 2021).

Best practices thus include validated per-call randomness, disabling response caching for nonce-including pages, cryptographic enforcement of nonce binding to protocol parameters, careful design and certification of hardware RNGs, and compile-time type policies.

Summary Table: Notable Nonce@Once Vulnerability Classes

Domain	Vulnerability	Exploit Consequence
ECDSA Signature	Affine/reused k	Private key recovery from 2 signatures
CSP Web Security	Nonce reuse (server/cache)	XSS bypass via injected script with reused N
EMV Payments	Predictable UN	Pre-play attack, card cloning
AEAD Cryptography	Nonce/key pair reuse	Ciphertext forgery, plaintext recovery
ML Black-box Attacks	Single-query universal δ	Universal adversarial samples

The Nonce@Once attack framework unifies vulnerabilities arising from cryptographic protocol design, implementation errors, system misconfigurations, and insufficiently expressive programming models, emphasizing the necessity of discipline in nonce generation and enforcement across diverse platforms and threat models.