The public signature is allowed to travel.

The private key is not.

Between them sits a smaller secret that people keep underestimating:

the per-message nonce

In DSA and ECDSA, signing a message spends a fresh secret value, traditionally called (k). The verifier does not learn (k). The signature does not print (k). But the signature equation contains (k) in exactly the place where a bad implementation can turn one public artifact into a private-key leak.

For ECDSA, with private key (x), message hash (e), public signature ((r,s)), and group order (n), the important line is:

\[s \equiv k^{-1}(e + rx) \pmod n.\]

That is the whole trap.

The curve can be strong. The hash can be strong. The verifier can be correct. If (k) repeats or becomes predictable, the private key walks out through the side door.

The Standard Knows This

FIPS 186-5 is blunt about ECDSA’s per-message secret. Before each ECDSA signature, a new secret random number (k) is required, and that value has to be protected from disclosure and modification.1 The standard also approves deterministic ECDSA via RFC 6979, which replaces the “please have good entropy every time” requirement with a specified HMAC-DRBG construction keyed by the private key and message.2

The point is not that randomness is bad. The point is that this randomness is part of the private key’s boundary.

If (k) is reused in two signatures with the same private key, the private key is no longer hiding behind elliptic-curve hardness. It is hiding behind a subtraction.

Start with two signatures:

\[s_1 \equiv k^{-1}(e_1 + rx) \pmod n\] \[s_2 \equiv k^{-1}(e_2 + rx) \pmod n.\]

Subtract:

\[s_1 - s_2 \equiv k^{-1}(e_1-e_2) \pmod n.\]

So:

\[k \equiv (e_1-e_2)(s_1-s_2)^{-1} \pmod n.\]

Then:

\[x \equiv (s_1k-e_1)r^{-1} \pmod n.\]

One reuse. Complete compromise.

A Toy Signature Lab

The browser lab below is not production ECDSA. It uses the same vulnerable signature equation over a small prime field:

s * k = h + r * x mod q

The public value r is derived from the hidden nonce as r = g^k mod q, which makes it a visible fingerprint of the nonce. Real DSA and ECDSA compute r with their actual group operation. The algebraic failure is the same shape.

The lab deliberately reveals the hidden k values in the table so the experiment can be audited. A real verifier would not see them.

The recovery routines do not have to trust that hidden table. The toy signer also publishes y = g^x mod q, so a recovered candidate key is checked against the public key and against the public signature equations.

nonce trace repeated or compromised verified recovery hidden nonce values linear relation

Deterministic toy signature experiment over q = 65537. The Node audit runs 1,317 checks: field arithmetic, public-key validation, signature equations, repeated-r recovery, tiny-nonce dictionary hits, linear-system recovery, fresh-nonce controls, and parameter sanitization.

Try four modes.

Reused nonce is the classic catastrophe. The r column repeats because the same hidden k was spent twice. The lab subtracts two signature equations, recovers k, then recovers the private key x.

Tiny nonce space is an offline dictionary. The attacker tries every possible small k, recomputes r = g^k mod q, and when r matches a public signature, solves for x. If your nonce has only eight bits of entropy, one signature is already enough in this toy.

Linear clock is more subtle. The r values do not repeat, and the nonces are not small. But if the signer uses a known relation

k_i = k0 + i * step

then each signature is a linear equation in the two unknowns x and k0. Two signatures solve the system.

Fresh nonces is the control. The tiny dictionary is still tried, but it does not hit the public r values, so the private key is not recovered by this attack model.

Partial Leaks Are Not Comforting

The lab’s tiny-space mode is intentionally crude. Real failures are often messier: a timing leak reveals a few bits, a biased generator avoids part of the range, a process counter mixes into k, or a signing path uses related nonces under latency pressure.

That messier world has been studied for decades. Howgrave-Graham and Smart described lattice attacks on DSA when a portion of the ephemeral signing keys is known.3 Nguyen and Shparlinski later gave provable recovery results for DSA with a few consecutive bits of the nonces known, and extended the story to ECDSA variants.45

The pattern is always the same:

signature equation + structure in k = equations about x

The attacker does not have to solve the discrete logarithm problem. The signer has accidentally replaced it with a smaller problem.

The Blockchain Version Is Especially Unforgiving

Blockchain signatures are public, indexed, permanent, and attached to assets. That makes nonce discipline more than an implementation detail. It becomes a forensic surface.

A 2026 arXiv preprint on Polygon MEV searchers reports systematic ECDSA nonce reuse and related nonce patterns in latency-sensitive workflows. The authors write the same core equation as a linear system and describe same-wallet reuse, linear nonce relations, and cross-wallet nonce collisions.6 I would treat the paper as a preprint, not a final industry census. But the lesson does not depend on one ecosystem: public signatures make repeated r values and structured nonces auditably dangerous.

Once a key leaks on-chain, “rotate later” may only protect the next funds.

A Signing Checklist

The defensive checklist is short and not glamorous:

use a reviewed signing library
use RFC 6979 or a well-audited deterministic/hedged construction when available
never improvise k from timestamps, counters, UUIDs, or hashes of convenient fields
monitor emitted signatures for repeated r values
test signer state across process restarts, forks, VMs, HSM failover, and load spikes
treat nonce precomputation with the same confidentiality as the private key
rotate immediately after any nonce anomaly

FIPS 186-5 says that precomputed (k) and (k^{-1}) have to be protected like the private key.1 That is the right mental model.

The nonce is not metadata.

It is a one-use private key fragment.

  1. NIST, “FIPS 186-5: Digital Signature Standard (DSS)”, 2023. Section 6.3 requires a new protected per-message secret number for ECDSA; Section 6.4 gives the ECDSA signature-generation equation. ↩ ↩2

  2. Thomas Pornin, “Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)”, RFC 6979, 2013. ↩

  3. Nick Howgrave-Graham and Nigel P. Smart, “Lattice Attacks on Digital Signature Schemes”, Designs, Codes and Cryptography 23(3):283-290, 2001. ↩

  4. Phong Q. Nguyen and Igor E. Shparlinski, “The Insecurity of the Digital Signature Algorithm with Partially Known Nonces”, Journal of Cryptology 15:151-176, 2002. ↩

  5. Phong Q. Nguyen and Igor E. Shparlinski, “The Insecurity of the Elliptic Curve Digital Signature Algorithm with Partially Known Nonces”, Designs, Codes and Cryptography 30(2):201-217, 2003. ↩

  6. Yash Madhwal, Andrey Seoev, Raffaele Della Pietra, Anastasiia Smirnova, and Yury Yanovich, “Chain Reactions: How Nonce Collisions in ECDSA Compromise Polygon MEV Searchers”, arXiv:2605.21498, 2026. ↩