Few RFCs can claim to have single-handedly rescued an entire class of cryptographic signatures from their own worst enemy. RFC 6979 is one of them. Written by French cryptographer Thomas Pornin, it takes a single, deceptively small problem — how to pick the random number k when signing with DSA or ECDSA — and gives it a rigorous, deterministic answer.

The problem: k is a landmine. Every DSA/ECDSA signature requires a fresh, uniformly random per-message secret called the nonce, k. If k is ever reused across two different messages under the same private key, an attacker can recover the private key with schoolbook algebra. Worse, if k is even slightly biased or partially predictable, lattice attacks (Bleichenbacher, Howgrave-Graham–Smart) can extract the key from a handful of signatures.

This is not theoretical. In 2010, Sony's PlayStation 3 code-signing key was extracted because Sony's ECDSA implementation used a constant k. Every signature leaked the master key. Bitcoin's Android wallet suffered a 2013 incident where a weak SecureRandom caused nonce collisions and stolen coins. Blockchain analysis of Ethereum has repeatedly found reused nonces exposing wallets.

Pornin's insight. The signer already has two things: the private key x and the message hash h. Together, these contain more than enough entropy to derive a nonce that is unique, unpredictable to anyone else, and free of bias. RFC 6979 specifies exactly how: run HMAC-SHA-256 (or any hash) in a well-defined loop over x and h, using HMAC as a PRF in a construction lifted almost verbatim from NIST SP 800-90A's HMAC_DRBG. The output is a k in the valid range [1, q-1], produced with rejection sampling to avoid modular bias.

Key design decisions:

• Deterministic, not random. Given the same key and message, you always get the same signature. This is a feature: it's testable, reproducible, and immune to bad RNGs.
• HMAC-based, not raw hash. HMAC gives clean domain separation and PRF security assumptions that raw SHA(x || h) lacks.
• Rejection sampling. Naïvely reducing a hash output modulo q produces subtle bias when q is not a power of two; RFC 6979 rejects out-of-range candidates and iterates.
• Backwards compatible. The signature format is unchanged. A deterministic signature verifies with any standard ECDSA verifier. Adoption cost: essentially zero.
• Optional entropy input. A later erratum-era practice (and RFC 6979bis discussion) allows mixing extra randomness in to defend against fault-injection attacks — best of both worlds.

Why it matters today. Practically every modern cryptographic library — OpenSSL, BoringSSL, libsodium's Ed25519 relatives, Bitcoin Core's libsecp256k1, Go's crypto/ecdsa (since 1.19, silently), Python's cryptography, Rust's k256 — either defaults to or offers RFC 6979 signing. Bitcoin, Ethereum, Monero, TLS certificates, SSH host keys, code-signing pipelines: all lean on it. The RFC quietly eliminated an entire attack surface that had bled real money and real secrets for two decades.

A footnote of history. Ed25519 (RFC 8032, 2017) took the same idea further: deterministic nonces are baked into the algorithm itself, not bolted on. In that sense, RFC 6979 was the bridge — retrofitting NIST curves and legacy DSA with the safety property that newer schemes now consider table stakes.