One Number, Used Twice: How a Repeated Nonce Hands Over Your Private Key -- and How Determinism Takes It Back

1. One Number, Used Twice#

In December 2010, on stage at the 27th Chaos Communication Congress in Berlin, three researchers working under the name fail0verflow explained how they had recovered the master private key that anchors the entire PlayStation 3 chain of trust ^[1]. There was no brute force, no exotic side channel, no supercomputer grinding for months. There were two signatures and the kind of algebra you learned before you were old enough to drive. Sony had signed its code with ECDSA, the elliptic-curve digital signature algorithm, and Sony had signed every firmware image with the same secret per-signature number. Two events that are often merged into one: fail0verflow disclosed the constant-nonce flaw at 27C3 in December 2010; George Hotz, known as geohot, separately published an extracted PS3 root key in January 2011 ^[9]. The talk revealed the mechanism; the key release came afterward. Keep them distinct.

Sit with how strange that is. The console's security rested on a signature scheme that most cryptographers would call sound. AES was not broken. The elliptic curve was not broken. The signature math was not broken. One input was reused, and the entire trust anchor fell out of a schoolbook manipulation that a motivated teenager could reproduce on paper.

Now the mirror image, in a completely different primitive. In 2016, a team scanning the live internet found 184 public HTTPS servers repeating a different one-time number -- the AES-GCM initialization vector -- and reported that this "fully breaks the authenticity of the connections" ^[3]. Not the confidentiality of a lab toy: the authenticity of real TLS sessions on the open web, letting an attacker forge messages the server would accept as genuine.

Same disease, entirely different organ. One is a signature that proves who you are; the other is the cipher that guards most of the web's traffic. Both staked everything on a number that was supposed to be used correctly exactly once.

That shared bet is the subject of this article. Both primitives depend, silently, on a value that must be unique and unpredictable -- once, per key. The precise question: what, exactly, does each stake on that number, and what is the exact cost of getting it wrong? For the repeat case, the answer is total and immediate -- and the algebra is short enough to print in full.

In cryptography, reusing one number can cost you everything.

That is the punchline, and by the end you will have earned it rather than taken it on faith -- the full key-recovery algebra, Antoine Joux's cipher attack, the statistical cousin that needs only a fraction of a leaked bit, and the deterministic designs that dissolve the whole failure family. But how can two signatures undo an entire console's chain of trust? To see it, we first have to meet the number both of these primitives are quietly betting everything on.

2. The Secret Number Both Primitives Depend On#

Two algorithms, designed decades and a world apart -- a discrete-logarithm signature and a block-cipher mode of authenticated encryption -- turn out to share a single point of failure. Before we can watch it break, we need to know where the number comes from and why it has to exist at all.

The signature side is the older lineage. ElGamal's 1985 signature scheme introduced a per-signature secret exponent ^[10], and when the United States standardized the Digital Signature Algorithm as FIPS 186 in 1994 ^[11], that per-signature secret came along for the ride. Its elliptic-curve descendant, ECDSA, keeps it. The value is called the signing nonce, written $k$, and it is regenerated fresh for every single signature.

The cipher side is younger. When NIST standardized Galois/Counter Mode in SP 800-38D in 2007, the specification required that the initialization vector -- the $\text{IV}$, GCM's nonce -- be distinct for every message encrypted under a given key ^[12]. Same structural demand, opposite secrecy requirement: the signing nonce must be secret, while the GCM nonce may be completely public. What both must be is fresh.

Now put the two governing equations side by side. An ECDSA signature on a message whose hash (as an integer) is $z$, under private key $d$, is the pair $(r, s)$:

$r = (k \cdot G)_x \bmod n, \qquad s = k^{-1}\,(z + r\,d) \bmod n$

Here $G$ is the fixed base point, $n$ its prime order, $d$ the private key, and $r$ is the x-coordinate of the curve point $k \cdot G$ reduced modulo $n$. The AES-GCM authentication tag on ciphertext $C$ with additional data $A$ is:

$T = E_K(J_0) \oplus \mathrm{GHASH}_H(A, C), \qquad H = E_K(0^{128})$

$E_K$ is AES under key $K$; $J_0$ is a pre-counter block derived from the IV; $\mathrm{GHASH}_H$ is a polynomial hash over the field $\mathrm{GF}(2^{128})$ keyed by the secret subkey $H$, which is simply AES applied to the all-zero block.

Look at what both equations hide inside them. The signing equation multiplies the private key $d$ by the public $r$ and masks it behind $k$. The tag equation masks the keyed hash behind the one-time pad $E_K(J_0)$, which is a deterministic function of the nonce. In each case, one freshly chosen value is the only thing standing between a routine operation and a full disclosure. That gives us the single shared contract, short enough to fit on one line: the number must be unique and unpredictable, exactly once, per key.

None of this was a secret to the designers. Bellare, Goldwasser, and Micciancio analyzed the danger of a poorly generated DSA nonce as early as their 1997 CRYPTO paper, "The DSS case" ^[13], showing that a linear-congruential nonce generator breaks the scheme. Terminology drifts across modes, so fix it now: a nonce need only be unique (CTR, GCM); an IV for CBC must additionally be unpredictable; a salt is unique and public and feeds a KDF. The mode dictates which property is load-bearing. Part 2 and the block-cipher-modes installment work through the distinctions; here we only need "fresh, once, per key." The contract was understood from the beginning; nobody misunderstood the rule. They simply could not always keep it.

The contract says "never repeat." So begin with the crudest possible violation -- the same number, twice -- and watch precisely how much it costs.

3. Two Signatures, One k, and Your Private Key#

This is the entire thesis compressed into one page of algebra -- no lattice, no side channel, no probability, just subtraction and one division. How little work does complete key recovery actually take?

Start from the fact that makes it possible. The first signature component, $r = (k \cdot G)_x \bmod n$, depends only on the nonce $k$ and the fixed public base point $G$. It does not depend on the message. So if you sign two different messages under the same $k$, both signatures carry the identical $r$. That repeated $r$ is the visible tell -- a fingerprint an attacker can spot by scanning a signature log, with no secret knowledge at all. This is exactly what fail0verflow read off the PlayStation 3: every firmware signature carried the same $r$, the public fingerprint of a constant $k$. You do not need to break anything to notice it; you just look for two signatures with a matching first half.

Now write the two signing equations under that shared $k$:

$s_1 = k^{-1}(z_1 + r\,d) \pmod n, \qquad s_2 = k^{-1}(z_2 + r\,d) \pmod n$

Subtract the second from the first. The private key appears only inside the identical $r\,d$ term, so it cancels completely:

$s_1 - s_2 = k^{-1}\big((z_1 + r\,d) - (z_2 + r\,d)\big) = k^{-1}(z_1 - z_2) \pmod n$

Every quantity on the right except $k$ is public: the two message hashes $z_1, z_2$ and the two signature halves $s_1, s_2$. So solve for the nonce directly:

$k = (z_1 - z_2)\,(s_1 - s_2)^{-1} \bmod n$

One subtraction on top, one modular inverse on the bottom. With $k$ in hand, substitute back into the first equation -- multiply through by $k$, subtract $z_1$, and divide by the public $r$:

$s_1 k = z_1 + r\,d \implies d = (s_1 k - z_1)\,r^{-1} \bmod n$

That is the private key. Count the cost to the attacker: two signatures, a handful of modular operations, ※ Constant work here means a fixed number of field operations, independent of the key size. A 256-bit curve is no harder to break this way than a 160-bit one, because the attack never touches the key's length. and the recovery is certain -- not probable, not "on average," but exact, every time, the moment the repeat occurs. It solves a two-by-two linear system that the reuse handed over for free.

flowchart TD
A["Two signatures made under the same nonce k"] --> B["They share the same r, because r depends only on k and G"]
B --> C["Subtract the two s equations"]
C --> D["The r times d term cancels, leaving k as the only unknown"]
D --> E["One modular inverse recovers k"]
E --> F["Put k back into either s equation"]
F --> G["The private key d falls out, with certainty"]

You do not have to take the algebra on faith -- here is the whole attack as runnable code over a toy curve order, recovering the private key from public values alone:

// Recover the ECDSA private key d from two signatures sharing nonce k.
function egcd(a, b) {
if (b === 0n) return [a, 1n, 0n];
const [g, x, y] = egcd(b, a % b);
return [g, y, x - (a / b) * y];
}
function modInv(a, n) {
a = ((a % n) + n) % n;
const [g, x] = egcd(a, n);
if (g !== 1n) throw new Error('no inverse');
return ((x % n) + n) % n;
}

const n = 1103n;   // toy prime "curve order" (real curves use ~256-bit n)
const d = 937n;    // the SECRET key the attacker must not know
const k = 421n;    // the reused nonce (identical for both signatures)
const r = 668n;    // r = (k*G).x mod n -- SHARED because k is shared
const z1 = 123n, z2 = 456n;  // two different message hashes

// Victim signs both messages with the SAME k:
const s1 = (modInv(k, n) * (z1 + r * d)) % n;
const s2 = (modInv(k, n) * (z2 + r * d)) % n;

// Attacker sees only public (r, s1, z1, s2, z2). Recover k, then d:
const kRec = ((((z1 - z2) % n) + n) % n) * modInv((((s1 - s2) % n) + n) % n, n) % n;
const dRec = ((((s1 * kRec - z1) % n) + n) % n) * modInv(r, n) % n;

console.log('shared r    :', r.toString());
console.log('recovered k :', kRec.toString(), '(true k =', k.toString() + ')');
console.log('recovered d :', dRec.toString(), '(true d =', d.toString() + ')');
console.log(dRec === d ? 'PRIVATE KEY RECOVERED from two signatures.' : 'mismatch');

Two signatures sharing one nonce equal certain, instant, total key recovery -- by hand, with pure algebra. Reuse is not a slope that gradually weakens security; it is a cliff. "Reuse one number equals everything" is a literal statement about ECDSA, not a rhetorical flourish.

This is not a museum piece. The PlayStation 3 fell to exactly this -- a constant $k$ across every firmware signature, two images sharing one $r$, the master key recovered ^[1]. Section 5 catalogs the rest of the real-world chain, from that constant-nonce break down to biases of less than a single bit.

Certainty from a literal repeat is the easy case -- easy for an attacker to run, and, as we will see, easy for a defender to eliminate. So attackers asked a sharper and far more dangerous question. What if the nonces are never equal, only slightly, invisibly skewed?

4. From Repeat to Bias: The Hidden Number Problem#

You do not need the nonces to be equal. You only need them to be a little bit predictable -- and then to collect enough of them. This is where the story turns, because it dismantles the comforting fix you probably just thought of. If a literal repeat is the danger, surely "make sure the nonces are always different" closes it? It does not come close.

Here is the shift in viewpoint. In Section 3, a repeat gave us an exact equation and we solved it. Now suppose each nonce is merely skewed -- say the top few bits are always zero, or the generator leans slightly toward small values. No two nonces are equal, so the certainty attack never triggers. But each signature is now a noisy linear equation relating the public data to the secret key $d$ modulo $n$, with the unknown nonce constrained to a smaller range than it should occupy. One such equation tells you almost nothing.

Stack hundreds or thousands of them as the rows of a lattice, though, and the secret $d$ shows up as one unusually short vector hiding in that grid. A reduction algorithm hunts it down, and the key reads straight out.

The genealogy is worth knowing, because each step needed less leakage than the last. Boneh and Venkatesan framed the Hidden Number Problem in 1996 ^[14]. Around 2000, Daniel Bleichenbacher showed that even a tiny statistical bias in DSA nonces is exploitable through a Fourier-analytic version of the same idea. Bleichenbacher's seminal biased-nonce result was never published as a standalone paper. It survives as a 2000 IEEE P1363 presentation and a 2005 CRYPTO rump-session talk, "Experiments with DSA," and is reconstructed through the reference lists of later work such as Nguyen-Shparlinski and LadderLeak. A standalone Bleichenbacher paper on this would be a fabrication; the history genuinely has this shape.

Nick Howgrave-Graham and Nigel Smart made the lattice attack practical in 2001, recovering keys from partially known nonces ^[15]. Phong Nguyen and Igor Shparlinski then proved rigorous polynomial-time ECDSA key recovery from just a few leaked nonce bits per signature in 2003 ^[7]. Two decades on, LadderLeak pushed the frontier to its logical extreme, breaking ECDSA with less than one bit of nonce leakage per signature ^[8].

Now the distinction that everything downstream depends on. The biased case is not the repeat case with weaker numbers. It is a different kind of attack with a different cost profile, and conflating them is the single most common way this topic gets mistold.

Laid out side by side, the contrast is stark:

flowchart TD
A["Many signatures, each nonce slightly biased"] --> B["Each is a noisy linear equation in the secret d"]
B --> C["Stack the equations as rows of a lattice"]
C --> D["The secret d hides in one unusually short vector"]
D --> E["Lattice reduction finds that short vector"]
F["Read the private key d straight out of it"]
E --> F

The lesson lands hard. If even a fraction of one bit of bias, harvested across enough signatures, surrenders the key, then "never literally repeat $k$" is nowhere near enough of a rule, and "use a better random number generator" is a treadmill, not a fix. The only question left is how bad this got in real, shipped hardware -- devices built by careful engineers who knew all of this.

5. The Catastrophes in the Wild: ECDSA#

The theory is alarming; the field results are worse. What follows is the evolution told as a body count, and the number to watch is the leak the attacker needed. It shrinks with almost every entry, from an entire repeated nonce down to a fraction of a single bit, and every generation still won.

The 2010 PlayStation 3 break sits at one end: a constant nonce across all firmware signatures, the maximum possible leak, two signatures sufficient ^[1]. In 2013 the Android SecureRandom defect produced repeated and predictable signing nonces on mobile devices; because Bitcoin wallets sign transactions with ECDSA, attackers drained the vulnerable ones ^[16]. Google's own writeup traced the root cause to improper initialization of the underlying PRNG in the Java Cryptography Architecture ^[17]. The often-repeated figure of roughly 55 BTC stolen in the 2013 Android incident comes from secondary news reporting ^[18]. The primary bitcoin.org advisory ^[16] names the flaw and the affected wallet apps but states no loss total. Treat the number as reported, not official.

Then the leak starts shrinking. Minerva (2020) attacked real smart cards and cryptographic libraries that leaked the bit-length of the nonce through timing -- a whisper of bias, not a repeat -- and recovered keys from "just 500 signatures for simulated leakage data, 1200 for real cryptographic library data, and 2100 for smartcard data" ^[19].

TPM-Fail (disclosed 2019, published at USENIX Security 2020) turned a timing side channel in Intel's firmware TPM (CVE-2019-11090) and an STMicroelectronics TPM (CVE-2019-16863) into nonce-bit leakage. It recovered an ECDSA key from the Intel fTPM in 4 to 20 minutes and, remotely, "the authentication key of a virtual private network (VPN) server in 5 hours" ^{[20] [21]}.

LadderLeak (2020) then broke ECDSA with less than one bit of nonce leakage per signature, exploiting a Montgomery-ladder side channel in OpenSSL ^[8], a result published at ACM CCS 2020 ^[22]. And in 2024, PuTTY's use of P-521 exposed a structural bias so clean it needs almost no data at all (CVE-2024-31497) ^[23].

"The first 9 bits of each ECDSA nonce are zero. This allows for full secret key recovery in roughly 60 signatures." -- the PuTTY P-521 disclosure ^[23]

Sixty signatures. An attacker who had watched roughly sixty SSH handshakes, or collected sixty signed Git commits, could reconstruct the user's private key. The affected PuTTY versions ran from 0.68 through 0.80 (fixed in 0.81), and the same biased generator shipped in FileZilla, WinSCP, TortoiseGit, and TortoiseSVN ^[23]. Collect them into one table and the trend is impossible to miss:

flowchart LR
A["1996 HNP framework: bias is exploitable in principle"] --> B["2010 PS3: a constant nonce, the whole value repeats"]
B --> C["2013 Android: predictable and repeated nonces"]
C --> D["2020 Minerva and TPM-Fail: a few biased bits via timing"]
D --> E["2020 LadderLeak: less than one bit per signature"]
E --> F["2024 PuTTY P-521: nine fixed bits, about 60 signatures"]

Every entry above is a signature scheme bleeding out its private key through the nonce. You would be forgiven for thinking this is an ECDSA problem. It is not. The exact same structural flaw -- one number that must be used once and is fatal on reuse -- was hiding inside a completely different primitive, the cipher that protects most of the traffic on the modern web.

6. The Other Primitive: AES-GCM's Forbidden Attack#

Different math, a different decade, a different threat model -- and the exact same fatal dependency on one number used once. The puzzle here is sharper: AES-GCM's nonce is public, so how can reusing a value the attacker already knows leak a forgery key? The answer is Antoine Joux's forbidden attack, and it mirrors the signature story beat for beat.

Recall the tag from Section 2: $T = E_K(J_0) \oplus \mathrm{GHASH}_H(A, C)$, where $H = E_K(0^{128})$. Two facts about that formula are load-bearing. First, $H$ depends only on the key, so it is fixed for the whole life of that key. Second, $E_K(J_0)$ depends only on the key and the nonce, through the pre-counter block $J_0$. Reuse the nonce and $E_K(J_0)$ comes back identical.

Now reuse one $(\text{key}, \text{IV})$ pair on two messages. Two things break, and they break separately.

The confidentiality break, from a single collision. GCM encrypts with counter mode: the ciphertext is the plaintext XORed with a keystream generated from $J_0$. Same key, same IV means the same $J_0$, means the same keystream. So for two messages encrypted under the reused pair, $C \oplus C' = P \oplus P'$. The keystream cancels and the XOR of the two plaintexts falls out immediately, from just one collision, with no further work. If the attacker knows or guesses one plaintext, the other is fully revealed. Here is that leak as runnable code:

// Reuse one (key, IV) in a keystream mode -> C XOR C' leaks P XOR P'.
// GCM encrypts with AES-CTR: same (key, IV) reproduces the SAME keystream.
function xor(a, b) { return a.map((x, i) => x ^ b[i]); }
const bytes = s => Array.from(new TextEncoder().encode(s));
const hex = a => a.map(x => x.toString(16).padStart(2, '0')).join('');

// A fixed keystream stands in for AES-CTR(key, IV): identical for both messages.
const keystream = [0x9e,0x37,0x5a,0xc1,0x02,0xbb,0x44,0xd0,0x71,0x6f,0x88,0x2a];

const P1 = bytes('transfer=10 ').slice(0, keystream.length);
const P2 = bytes('transfer=9999').slice(0, keystream.length);

const C1 = xor(P1, keystream);   // ciphertext 1
const C2 = xor(P2, keystream);   // ciphertext 2, SAME keystream

// Attacker never sees the key or keystream -- only C1 and C2:
const leak = xor(C1, C2);        // == P1 XOR P2, the keystream cancels
console.log('C1 XOR C2 :', hex(leak));
console.log('P1 XOR P2 :', hex(xor(P1, P2)), '(identical -> keystream is gone)');

// If the attacker also knows P1, then P2 falls out immediately:
console.log('recover P2:', new TextDecoder().decode(new Uint8Array(xor(leak, P1))));

The authenticity break, from the tag difference. This is Joux's contribution. Write the two tags under the reused pair and XOR them. The identical blind $E_K(J_0)$ cancels exactly:

$T \oplus T' = \mathrm{GHASH}_H(A, C) \oplus \mathrm{GHASH}_H(A', C')$

Every block of $A, C, A', C'$ is observable on the wire, and $\mathrm{GHASH}_H$ is a polynomial in $H$ over $\mathrm{GF}(2^{128})$ with those blocks as coefficients. So the right-hand side is a known polynomial in the one unknown $H$, and it equals the observed left-hand side. Move everything to one side and you have a polynomial equation whose roots are candidate values for $H$; factoring it over $\mathrm{GF}(2^{128})$ yields that candidate set ^[2].

Recover $H$ and, since $E_K(J_0) = T \oplus \mathrm{GHASH}_H(A, C)$ falls out too, the attacker can compute a valid tag for any ciphertext they like under that nonce. That is a universal forgery.

flowchart TD
A["Tag T equals E_K(J0) XOR GHASH_H of the message"] --> B["J0 comes from the IV, H comes only from the key"]
B --> C["Reuse the same key and IV on a second message"]
C --> D["E_K(J0) is identical in both tags, so it cancels under XOR"]
D --> E["T XOR T-prime is a known polynomial in H over GF(2 to the 128)"]
E --> F["Its roots are the candidate values for the subkey H"]
F --> G["Two or more collisions pin H, enabling universal forgery"]

This is not confined to whiteboards. In 2016 the Nonce-Disrespecting Adversaries team scanned live TLS and "identified 184 HTTPS servers repeating nonces, which fully breaks the authenticity of the connections" ^[3]. Joux's result is his 2006 public comment to NIST, whose embedded document title reads "Authentication Failures in NIST version of GCM" ^[2]. It is sometimes miscited as IACR ePrint 2006/187 -- but that number is a different paper, on HMAC and NMAC, by Kim, Biryukov, Preneel, and Hong ^[24]. Cite the NIST comment, not the ePrint. These were production HTTPS endpoints, not lab toys, and their nonce reuse let anyone forge authenticated records against them. The canonical live-TLS evidence for GCM nonce reuse is that paper ^[3], not CVE-2016-0270, which concerns IBM Domino rather than OpenSSL. If you see that CVE cited as the OpenSSL GCM-reuse bug, it is a misattribution.

Two primitives, one disease: a once-per-operation number that is death on reuse. If the flaw is structural rather than a coding slip, then "be more careful with your randomness" cannot be the cure -- Section 5 already showed that treadmill has no end. The fix has to be architectural. What would that even look like?

7. Make the Number Deterministic#

The cure for a randomness disaster turned out to be less randomness. That sentence should feel wrong -- we have spent five sections watching bad randomness destroy keys, so surely the answer is better randomness. It is not, and seeing why is the moment the whole subject clicks into place.

Go back to what actually failed. The signing equation needs a $k$ that is unique and unpredictable. Every real break came from the runtime source of that $k$: a constant, a repeated PRNG output, a biased generator, a timing leak. So Thomas Pornin's RFC 6979 asks a disarming question -- what if we never draw $k$ from a runtime source at all? Instead, derive it, deterministically, from two things the signer already holds: the private key and the message ^[4].

Concretely, RFC 6979 runs an HMAC-based deterministic random bit generator, seeded from the private key $x$ and the message hash, and rejection-samples its output into the valid range $[1, n-1]$. The two helper encodings simply turn the key and the hash into fixed-width byte strings so the HMAC has well-defined inputs:

h  = H(message)                              # hash the message
V  = 0x01 0x01 ... 0x01                       # hlen bytes of 0x01
K  = 0x00 0x00 ... 0x00                       # hlen bytes of 0x00
K  = HMAC(K, V || 0x00 || int2octets(x) || bits2octets(h))
V  = HMAC(K, V)
K  = HMAC(K, V || 0x01 || int2octets(x) || bits2octets(h))
V  = HMAC(K, V)
loop:
    T = ""                                     # accumulate qlen bits of output
    while bitlen(T) < qlen:                    # one HMAC block if qlen <= hlen; more if longer
        V = HMAC(K, V);  T = T || V
    k = bits2int(T)
    if 1 <= k <= n-1:  return k               # in range -> use it
    K = HMAC(K, V || 0x00);  V = HMAC(K, V)    # else reseed and retry

Look at what this buys. The generator is seeded by the private key and the message, and nothing else, and two consequences close the generation side of the Part-A attack surface.

The repeat case dies because two different messages produce two unrelated nonces, while the same message reproduces the same signature harmlessly -- there is no runtime generator whose collision could hand you a shared $k$. The bias case dies wherever the bias was born in a generator: with no runtime generator in the loop, there is nothing to skew and no entropy pool to under-initialize. Every Section-5 break that lived in the generator -- the repeated $k$ on the PS3, the predictable $k$ from a weak SecureRandom -- has simply been removed from the design, because there is no generator left to fail.

Deterministic signers "do not need access to a source of high-quality randomness." -- RFC 6979 ^[4]

And the compatibility story is almost too good: a verifier cannot even tell. The verification equation is unchanged, because a signature is still just a valid $(r, s)$ pair; only the signer's method of choosing $k$ changed. Deployments can switch to deterministic signing unilaterally. You do not have to take the "same input, same output" claim on trust either:

// Deterministic nonce k = PRF(private key, message).
// Real RFC 6979 uses HMAC-DRBG; this toy uses a small deterministic mixer
// only to show the SHAPE: same (key,msg) => same k; different msg => unrelated k.
const MASK = (1n << 64n) - 1n;
const n = (1n << 61n) - 1n;              // toy prime modulus, k in [1, n-1]
function rotl(x, r) { return ((x << r) | (x >> (64n - r))) & MASK; }
function prf(key, msg) {                  // deterministic, consults no RNG
let h = 1469598103934665603n;           // 64-bit offset basis
for (const ch of (key + '|' + msg)) {
  h = (h ^ BigInt(ch.charCodeAt(0))) & MASK;
  h = (h * 1099511628211n) & MASK;       // FNV-style multiply
  h = rotl(h, 13n) ^ (h >> 7n);          // extra diffusion so 1 char avalanches
}
return (h % (n - 1n)) + 1n;              // map into [1, n-1]
}
const sk = 'private-key-0xA1B2';
console.log('k(pay Bob 10) :', prf(sk, 'pay Bob 10').toString());
console.log('k(pay Bob 10) :', prf(sk, 'pay Bob 10').toString(), '<- identical, no RNG consulted');
console.log('k(pay Bob 11) :', prf(sk, 'pay Bob 11').toString(), '<- unrelated');
console.log('No source of runtime randomness was consulted.');

The same idea has a sibling that was born deterministic. EdDSA, and its popular instantiation Ed25519, does not bolt determinism on -- it designs the runtime randomness out from the start, computing its per-signature secret as a hash of a key-derived prefix and the message ^[5]. That is why Ed25519 has no separate "use RFC 6979" mode: there is no runtime nonce anywhere in the scheme to bias or repeat. Determinism is not an option you enable; it is the definition.

Standards bodies followed the evidence: FIPS 186-5, the current US signature standard, now approves deterministic ECDSA "as specified in IETF RFC 6979" ^{[25] [26]}. There is even a quiet operational bonus. A deterministic signer is testable: you can ship known-answer test vectors and check byte-for-byte that an implementation is correct, which a randomized signer can never offer.

The fix for a randomness failure was to remove the randomness. Derive the nonce from the private key and the message, and there is no runtime generator left to repeat or bias -- both failure modes vanish together.

Determinism looks like a clean, total victory. It is narrower than that, and the boundary matters. What it closes is the generation side of Part A. It does nothing for the usage side: recall that Minerva, TPM-Fail, and LadderLeak never touched a generator -- they read the nonce's leading bits out of the timing of the scalar multiplication $k \cdot G$, and that leak is present no matter how $k$ was chosen ^{[19] [20] [8]}. Determinism fixes generation, not usage; the defense against that class is a constant-time scalar multiplication, a separate discipline that RFC 6979 neither provides nor promises. Worse, determinism can even add exposure: by making signing perfectly repeatable, we hand a fault-injection attacker a perfectly repeatable target, a hazard RFC 6979's own security considerations acknowledge ^[4]. If Go's standard library knows this well enough to refuse pure determinism on purpose, we had better find out what it is afraid of.

8. The Catch, and the Hedge#

Here is a fact that should stop you: Go's standard library signs ECDSA non-deterministically on purpose, and its source code says so in a comment. After seven sections arguing that runtime randomness is the enemy, one of the most widely used standard-library signers refuses to remove it. That is not carelessness. It is a second threat model.

Determinism closed the randomness door, but it opened a different one. A deterministic signer computes the same signature every time for a given input, which means an attacker who can run it twice on the same message gets two identical computations to compare -- and comparison is exactly the lever a fault attack pulls.

This is not hypothetical. Aranha, Orlandi, Takahashi, and Zaverucha proved that de-randomized Fiat-Shamir schemes -- EdDSA among them -- are vulnerable to differential fault attacks ^[27]. And the standard itself agrees: FIPS 186-5 warns that fault attacks are "of particular concern for ... deterministic signature schemes, as well as embedded or IoT devices and smartcards" ^[26]. The very property that made determinism testable and repeatable -- same input, same output -- is what hands a fault attacker a fixed target to hammer.

The resolution is not to retreat to randomized signing, which reintroduces every repeat and bias failure. It is to take a small step back toward randomness, on purpose and in a controlled way: hedged signatures.

Read that definition twice, because it is the whole trick. Hedging is not "randomized signing with extra steps." It is a design that is safe whichever thing goes wrong. Lose your entropy source entirely and you fall back to RFC 6979's determinism, which we already proved kills repeat and bias. Keep your entropy and you also get a moving target that defeats the fault attack determinism exposed. The randomness is present but no longer load-bearing.

"Signatures generated by this package are not deterministic, but entropy is mixed with the private key and the message, achieving the same level of security in case of randomness source failure." -- Go crypto/ecdsa ^[28]

That is why Go hedges by default, and it is not alone. BoringSSL's FIPS module passes "a SHA512 hash of the private key and digest as additional data into the RBG ... a hardening measure against entropy failure" ^[29]. RFC 6979 itself sanctions hedged variants in its Section 3.6 ^[4], and FIPS 186-5 specifies an "Extra Random Bits" method that draws a nonce at least 64 bits longer than needed so any statistical bias becomes negligible ^[26].

The honest caveats: hedging still consumes some entropy, and its security proofs cover specific fault classes rather than all conceivable faults. It is a well-chosen trade, not a free lunch.

The right mental model is three parallel choices selected by threat model, not a podium with one winner:

So the signature side does not settle on a single champion. It settles on a matched set of choices, each correct for a different adversary. That is a satisfying place to land -- but it is only half the patient. What is the symmetric-encryption analogue for the cipher we left bleeding in Section 6?

9. Fixing the Cipher: Nonce-Misuse-Resistant AEAD#

The signature fix was "derive the number." The cipher's fix rhymes: derive the IV from the message itself, so that the worst a repeat can leak is the fact that two messages were byte-for-byte identical. Same instinct, symmetric setting.

The idea predates AES-GCM-SIV. Phillip Rogaway and Thomas Shrimpton gave it a provable-security treatment in 2006, defining deterministic authenticated encryption and the Synthetic IV construction that realizes it ^{[30] [31]}. It was standardized as AES-SIV in RFC 5297 ^[32].

The modern instantiation is AES-GCM-SIV (RFC 8452) ^[6]. It computes a keyed hash of the entire plaintext and associated data using POLYVAL, and folds that into a synthetic IV that doubles as the authentication tag; the synthetic IV then seeds ordinary AES-CTR encryption. POLYVAL is a little-endian relative of GHASH, chosen deliberately so AES-GCM-SIV can reuse the same carry-less multiplication hardware that already accelerates AES-GCM. The parallel to GCM is by design, not coincidence.

Two more refinements matter: fresh message-authentication and message-encryption keys are derived per nonce from the master key, which also pushes back the birthday bound that limits plain GCM and raises the safe message limit to roughly $2^{50}$ per key ^[33]. The price is structural and unavoidable: because the tag depends on the whole plaintext, you cannot emit the first ciphertext byte until you have read the last plaintext byte. AES-GCM-SIV is inherently two-pass and not online.

flowchart TD
A["Master key and nonce"] --> B["Derive per-message auth and encryption keys"]
P["Plaintext and associated data"] --> C["POLYVAL hash under the derived auth key"]
B --> C
C --> D["Synthetic IV, which doubles as the authentication tag"]
D --> E["Seed AES-CTR encryption with the synthetic IV"]
B --> E
E --> F["Output ciphertext and tag"]

Now state precisely what "misuse-resistant" earns you, because the phrase invites overclaiming. On a nonce repeat, AES-GCM-SIV discloses only whether the two messages "were equal or not," which RFC 8452 identifies as "the minimum amount of information that a deterministic algorithm can leak" ^[6]. Compare that to Section 6, where a single GCM repeat surrendered $P_1 \oplus P_2$ and set up universal forgery. The SIV construction converts a catastrophe into a whisper.

On nonce reuse, a misuse-resistant AEAD discloses only "whether the messages were equal or not ... the minimum amount of information that a deterministic algorithm can leak." -- RFC 8452 ^[6]

There is a parallel path worth knowing, though it solves a slightly different problem. XChaCha20-Poly1305 extends the nonce to 192 bits, which makes random nonce selection collision-safe and lets systems stay stateless without a counter ^[34]. That is genuinely useful, but it is not true misuse resistance: an exact nonce repeat still breaks Poly1305 the way any keystream reuse does. A big nonce makes accidental collisions astronomically unlikely; it does not make a deliberate repeat safe. Collect the options:

Two families, one move. On the signature side we stopped trusting runtime randomness by deriving the number; on the AEAD side we stop trusting it by making a repeat non-catastrophic. It feels, at last, like the problem is solved. It is not -- and the reasons are not missing features anyone can build. Some of them are walls that no amount of engineering can move.

10. Theoretical Limits and the Open Frontier#

Some of the walls we keep hitting are not missing features that a cleverer engineer will one day supply. They are proofs that you cannot have everything at once.

Those two impossibilities explain the shape of everything in Sections 7 through 9. AES-GCM-SIV is two-pass because it has to be. Hedged signatures exist because determinism alone cannot cover the fault case. We did not fail to find the one perfect design; the one perfect design is provably not there.

A third limit is epistemic, and it is the quiet engine under this entire article.

And the biased-nonce frontier is still descending: LadderLeak's sub-one-bit result is the current floor, not a proven bottom ^[8]. The theoretical minimum bias that remains exploitable is an open question, and history says to bet on "smaller than you think."

Then there is the genuinely open ground, where the same disease is re-emerging one abstraction level up. In threshold and multi-party ECDSA, several parties must jointly produce a nonce that is unbiased and secret from all of them, even when some participants misbehave. That is the Hidden Number Problem wearing a new coat: get the joint nonce generation subtly wrong and the biased-nonce attacks come straight back ^[35]. On the AEAD side, none of the four ciphers we surveyed is key-committing, and that gap is exploitable.

Julia Len, Paul Grubbs, and Thomas Ristenpart showed that this non-committing property turns certain systems into partitioning oracles that recover passwords and keys ^[36]. There is no drop-in standard for committing AEAD yet -- an active research front. It is worth being precise about what is not open, though: AES-GCM-SIV and AES-SIV already sit exactly at the minimum-leakage lower bound for the misuse case, because "leaks only equality" is provably optimal for any deterministic scheme ^[6]. That specific gap is closed; you cannot do better, and you do not need to.

Step back and the emotional arc completes. We began thinking nonce reuse was sloppy hygiene, discovered it was a cliff, thought determinism sealed the cliff, learned determinism opened a fault door, and now find that some of the remaining doors are welded shut by theorems while others open onto genuinely unexplored rooms. None of that theory, however, changes what an engineer should actually do on Monday morning. After all of it, what do you type?

11. What a Practitioner Does Today#

Everything above collapses into a decision tree that fits on an index card. You do not need to re-derive Joux's polynomial in a code review; you need two questions for signing and two for encryption.

For signing: for any (EC)DSA or DSA signer, derive the nonce with RFC 6979 or a hedged variant rather than drawing it at runtime ^[4]. For greenfield systems, prefer Ed25519, which is deterministic by construction ^[5]. If fault injection is a realistic threat -- smart cards, HSMs, IoT silicon an attacker can hold -- hedge, so an entropy failure degrades to safe determinism and a glitch still faces a moving target ^{[27] [29] [28]}. And never compute a nonce as rand() mod n from a raw PRNG without the anti-bias margin FIPS 186-5 specifies as Extra Random Bits ^[26]. On hardware whose timing an attacker can measure -- smart cards, TPMs, co-located VMs -- pair all of this with a constant-time scalar multiplication: RFC 6979 fixes how $k$ is generated, not how it is used, so the Minerva, TPM-Fail, and LadderLeak timing leaks close only when $k \cdot G$ itself runs in constant time ^{[19] [20] [8]}.

For AEAD: if you can guarantee a unique nonce -- a reliable, non-resetting counter -- AES-GCM is the fastest choice, provided you cap invocations per key against the birthday bound and rekey before you approach it ^{[12] [6]}. If nonce uniqueness is even slightly uncertain -- multiple writers sharing a key, VM snapshots that replay state, forked or stateless workers -- reach for AES-GCM-SIV ^[6] or the 192-bit-nonce XChaCha20-Poly1305 ^[34]. For deterministic key-wrapping, AES-SIV is purpose-built ^[32].

flowchart TD
S["Signing (EC)DSA or DSA"] --> Q1{"Fault injection in scope, such as smartcard or HSM or IoT"}
Q1 -->|Yes| H["Hedge: nonce from key, message, and fresh entropy"]
Q1 -->|No| G{"Greenfield design"}
G -->|Yes| ED["Prefer Ed25519"]
G -->|No| R6["Deterministic RFC 6979"]
A["Choosing an AEAD"] --> Q2{"Reliable unique nonce counter"}
Q2 -->|Yes| GCM["AES-GCM, cap invocations and rekey"]
Q2 -->|No| MR["AES-GCM-SIV or XChaCha20-Poly1305"]

The same choices read cleanly as a do-and-do-not table:

Two rules for two primitives, resting on a single instinct. That instinct is strong enough to design around -- but a handful of persistent myths still surface in code review and threat models, and each one hides a real misunderstanding of the mechanism. Let us dismantle them one at a time.

12. Frequently Asked Questions#

13. One Cure for Two Catastrophes#

Return to that stage in Berlin in 2010, but now you can see the whole shape of the thing. The PlayStation 3 master key did not fall to a broken cipher or a weak curve; it fell to one number, used twice, and two signatures' worth of subtraction ^[1]. The same shape swept real Bitcoin wallets when Android's generator repeated nonces ^[16].

Then the required leak kept shrinking -- bit-length timing on smart cards ^[19], side channels in TPMs ^[20], less than a single bit in LadderLeak ^[8], nine fixed bits and sixty signatures in PuTTY ^[23] -- and the very same disease surfaced in a cipher, where 184 live TLS servers reusing a GCM nonce were shown forgeable ^[3].

Every one of those failures shares a single sentence. Both primitives bet everything on a number that had to be unique and unpredictable exactly once, and both collapsed the moment that bet was lost. And the cures share a single sentence too. Deterministic signing derives the number from the key and the message so there is nothing left to repeat or bias ^[4], while a constant-time scalar multiplication closes the side-channel leaks that determinism never touched; hedged signing keeps a sliver of entropy so a fault has no fixed target ^[27]; misuse-resistant encryption derives the IV from the message so a repeat leaks only that two messages matched ^[6].

Two primitives, one disease, one cure: stop trusting runtime randomness for the once-per-operation number. Derive it, or make a repeat non-catastrophic. Everything else in this article is a footnote to that sentence.

Part 2 of this series taught the two ways randomness betrays you; this was the promised descent into what those betrayals actually cost and how the field designed them away. The punchline you were promised at the start has been earned line by line: in cryptography, reusing one number can cost you everything -- so build systems that never require you to trust yourself to use it only once.