ECDSA needs a fresh, unpredictable secret value, usually called k, for every signature. If it is biased, predictable or repeated, the signing key can be recovered. Ed25519 and RFC 6979 style ECDSA derive that value from the key and message instead, so a weak random source cannot ruin signing.
The failure in plain terms
A signature mixes your private key with the per-signature value k. The math lets a verifier check the result without learning either. But if the same k is used for two different messages, algebra on the two signatures reveals the private key. Even small biases across many signatures can leak enough to be exploited with lattice methods.
RFC 6979 puts it this way: k must be chosen randomly and uniformly with a cryptographically secure process, and even slight biases can be turned into attacks on the signature scheme.
The fix: derive k
RFC 6979 replaces random k with a value derived from the private key and the message hash through an HMAC-based generator. Same key and message always give the same k and the same signature. No random source is needed at signing time, the output is a standard ECDSA signature, and existing verifiers and keys keep working.
Ed25519, defined in RFC 8032, takes the same idea further. Signing hashes the private key with SHA-512, keeps part of the result as a prefix, and hashes that prefix with the message to get the nonce. Keys and public keys are 32 bytes and signatures are 64 bytes.
What to do in a project
- If you pick a signing algorithm freely, Ed25519 is a good default where your ecosystem and any compliance list allow it.
- If you need ECDSA over P-256 for compatibility, use a library that implements deterministic nonces, or one that documents its random source and tests it.
- Never write ECDSA signing yourself.
- Be careful with signing in environments where a virtual machine may be cloned or restored from a snapshot, because random state can repeat. Deterministic schemes help here.
- Hardware tokens and managed key services handle nonces internally. Check their documentation for how.
Related traps
Deterministic signing has its own caution in hardware: fault attacks can matter on devices an attacker can touch. For servers and apps this is rarely the main concern, but it is why some hardware designs mix random and deterministic input.
Also remember that a clean nonce does not fix a leaked private key. Rotate signing keys on a schedule and after any suspected exposure, using an approach like signing key rollover with overlapping keys.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each result names the exact place to fix.
Quick check
Is Ed25519 always better than ECDSA?
It is simpler to use safely, but ECDSA remains widely required for compatibility. Pick based on what your verifiers and standards support.
Does a deterministic nonce make signatures predictable to attackers?
No. The nonce depends on the private key, so without the key it cannot be predicted.
Sources
Last reviewed: 19 October 2026.
