Deterministic Nonce (RFC 6979)

What Is a Deterministic Nonce?

A deterministic nonce is a one-time number used in elliptic curve digital signature schemes (ECDSA and related algorithms) that is computed from the signer's private key and the message being signed, rather than generated randomly. The term "deterministic" means the same inputs always produce the same nonce, making the signing process reproducible and eliminating dependence on the quality of the system's random number generator (RNG).

RFC 6979, authored by Thomas Pornin and published in August 2013, defines the standard method for generating deterministic nonces. It uses HMAC-DRBG, a pseudorandom number generator specified in NIST SP 800-90A, seeded with the private key and the hash of the message. The result is a unique nonce for each unique (key, message) pair that is computationally indistinguishable from random output.

Before RFC 6979, ECDSA implementations relied on the operating system's RNG to produce nonces. If the RNG was broken, biased, or reused a value, an attacker could extract the private key from published signatures. Deterministic nonces solved this problem entirely by removing randomness from the equation.

How It Works

RFC 6979 replaces the random nonce selection step in ECDSA with a deterministic derivation using HMAC-DRBG. The process uses the same hash function that the signature scheme already employs (SHA-256 for Bitcoin's secp256k1 curve).

1. Compute the message hash: h1 = H(m), where H is the hash function and m is the message to sign
2. Initialize two internal HMAC-DRBG state variables: V (a sequence of 0x01 bytes) and K (a sequence of 0x00 bytes), each the length of the hash output
3. Seed the DRBG by computing K = HMAC_K(V || 0x00 || private_key || message_hash), then updating V = HMAC_K(V)
4. Reseed with a 0x01 separator: K = HMAC_K(V || 0x01 || private_key || message_hash), then V = HMAC_K(V)
5. Generate candidate nonce: produce bytes by iterating V = HMAC_K(V) until enough bits accumulate, then convert to an integer k
6. Validate: if 1 <= k <= q-1 (where q is the curve order), use k as the nonce. Otherwise, update K and V and retry

Pseudocode

The core HMAC-DRBG loop, simplified for a 256-bit curve like secp256k1:

// RFC 6979 deterministic nonce generation (simplified)
h1 = SHA256(message)
V  = 0x01 repeated 32 times
K  = 0x00 repeated 32 times

// Seeding steps
K = HMAC_SHA256(key=K, data=V || 0x00 || privkey || h1)
V = HMAC_SHA256(key=K, data=V)
K = HMAC_SHA256(key=K, data=V || 0x01 || privkey || h1)
V = HMAC_SHA256(key=K, data=V)

// Generation loop
loop:
  V = HMAC_SHA256(key=K, data=V)
  k = bits_to_int(V)
  if 1 <= k <= (curve_order - 1):
    return k   // valid nonce
  K = HMAC_SHA256(key=K, data=V || 0x00)
  V = HMAC_SHA256(key=K, data=V)

The private key never leaves the signing device during this process. The HMAC construction ensures that an observer who sees the resulting signature cannot reverse-engineer the nonce or the key.

Why HMAC-DRBG?

HMAC-DRBG was chosen because it is a well-analyzed, standards-compliant pseudorandom generator that accepts arbitrary seed material. It provides two critical properties: the output is indistinguishable from random to anyone who does not know the private key, and it is deterministic given the same inputs. This means signatures can be verified and reproduced in testing without introducing any security weakness.

Why It Matters

The history of ECDSA vulnerabilities demonstrates why deterministic nonces are essential. Every major nonce-related attack traces back to the same root cause: poor randomness.

The PlayStation 3 Key Extraction

In December 2010, researchers from fail0verflow revealed at the 27th Chaos Communication Congress that Sony had used a static nonce (the same k value) for all ECDSA signatures on PlayStation 3 firmware. With two signatures sharing the same nonce, the math to recover Sony's private signing key is straightforward: given signatures (r, s1) and (r, s2) with nonce k, the private key x = (s1 * m2 - s2 * m1) / (r * (s1 - s2)). This allowed anyone to sign and run arbitrary code on PS3 consoles.

The Android Bitcoin Wallet Thefts

In August 2013, a flaw in Android's Java SecureRandom implementation caused nonce reuse in ECDSA signatures for Bitcoin transactions. When a wallet signed multiple transaction inputs, the broken RNG could produce identical nonces, exposing the private key. Over 55 BTC were stolen from affected wallets, including Bitcoin Wallet, Blockchain.info, BitcoinSpinner, and Mycelium. This incident directly accelerated the adoption of RFC 6979 across the Bitcoin ecosystem.

Adoption in Bitcoin

Bitcoin Core adopted RFC 6979 deterministic signing in version 0.10.0, released on February 16, 2015. The switch was part of a broader effort to replace OpenSSL with libsecp256k1, a purpose-built elliptic curve library created by Pieter Wuille. The relevant pull requests (#5227 for deterministic signatures and #5506 for switching to libsecp256k1's built-in RFC 6979) made deterministic nonces the default for all Bitcoin Core signing operations.

Bitcoin Core also implements "low-r grinding": after generating the deterministic nonce, it checks whether the resulting r value's first byte is below 0x80. If not, it adds extra entropy using RFC 6979's Section 3.6 mechanism and tries again. This optimization reduces average transaction size by 1 byte, saving on fees over time.

Today, RFC 6979 is the standard across the ecosystem:

• libsecp256k1 uses RFC 6979 as its default nonce function, with an optional 32-byte extra entropy parameter
• Hardware wallets like Trezor implement RFC 6979 for all ECDSA signing
• Software wallets including Electrum and Sparrow use RFC 6979 with low-r grinding
• Major cryptographic libraries in Rust, Python, and Go implement RFC 6979 for their ECDSA modules

The adoption of Schnorr signatures via BIP-340 introduced a related but distinct approach: BIP-340 specifies its own deterministic nonce derivation using tagged hashes rather than HMAC-DRBG, optimized for the Schnorr scheme's algebraic structure. The underlying principle remains the same: derive the nonce from the private key and message to eliminate RNG dependence. For a deeper look at how Schnorr signatures improve on ECDSA, see the Taproot and Schnorr signatures explainer.

Use Cases

Embedded and Constrained Devices

Hardware wallets and signing devices operate in environments where high-quality randomness is difficult to guarantee. Microcontrollers may lack dedicated hardware RNG circuits, and software entropy sources on embedded systems are notoriously weak, especially immediately after boot. RFC 6979 eliminates this entire class of risk by removing the need for runtime randomness during signing.

Reproducible and Testable Signatures

Because the same inputs always produce the same nonce, implementations can be tested against known test vectors. The RFC itself includes test vectors for multiple curves and hash functions. This reproducibility is invaluable for cryptographic library audits, compliance testing, and cross-platform verification. Two independent implementations that produce identical signatures for the same key and message are almost certainly correct.

Threshold and Multi-Party Signing

In threshold signature schemes like FROST and MuSig2, nonce management becomes even more critical because multiple parties must coordinate. While these protocols define their own multi-round nonce generation, the underlying principle of deterministic derivation from secret inputs (rather than trusting each participant's RNG) carries forward. Compromised randomness at any single participant could otherwise jeopardize the entire group key.

Risks and Considerations

Fault Injection Attacks

The primary tradeoff of purely deterministic nonces: because the same (key, message) pair always produces the same signature, an attacker who can induce computational faults during the signing process can compare a faulty signature against the correct one for the same message. The difference reveals information about the nonce, and by extension the private key. Research presented at CT-RSA 2022 demonstrated that a 256-bit signing key can be recovered even with up to 250 faulty bits in a single faulted computation.

This attack vector is most relevant for hardware signing devices where an attacker has physical access. Voltage glitching, clock manipulation, and electromagnetic fault injection can all induce the targeted computational errors needed for this attack.

Fixed Signature Mapping

With deterministic nonces, signing the same message with the same key always produces an identical signature. While this is the feature that enables reproducibility, it also means an observer who sees the same signature twice knows the same key signed the same message twice. In most Bitcoin use cases this is not a concern because transaction hashes are inherently unique, but it could matter in protocols that sign repeated messages.

Synthetic Nonces as a Safeguard

Synthetic nonces (also called hedged nonces) combine the best of both approaches: they mix additional random bytes into the HMAC-DRBG seeding step alongside the private key and message hash. RFC 6979 Section 3.6 explicitly supports this through an optional "additional data" parameter.

If the RNG is functioning correctly, each signature receives a unique nonce, defeating fault injection attacks because an attacker can never obtain two signatures with the same nonce for comparison. If the RNG is broken or unavailable, the scheme degrades gracefully to standard RFC 6979 determinism, still preventing nonce reuse.

An IETF draft (draft-irtf-cfrg-det-sigs-with-noise, updated March 2025) formalizes this pattern as the recommended default for all new implementations. Go's standard library crypto/ecdsa package has implemented hedged nonces since Go 1.20, seeding an AES-CTR CSPRNG with the private key, system entropy, and message hash. The libsecp256k1 library accepts 32 bytes of optional extra data in its signing function for the same purpose.

Deterministic Nonces and Spark

Any system that handles Bitcoin digital signatures benefits from deterministic nonce generation. Layer 2 protocols like Spark involve frequent signing operations for state transitions and transfers. RFC 6979 ensures that these signing operations are safe regardless of the underlying platform's RNG quality, which is especially important for mobile and embedded wallet environments where Spark's SDK operates.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.