---
title: Deterministic Nonces in ECDSA
url: https://www.emergentmind.com/topics/deterministic-nonces-in-ecdsa
type: topic
---

# Deterministic Nonces in ECDSA

Deterministic nonces in the Elliptic Curve Digital Signature Algorithm (ECDSA) are nonces that are deterministically derived from the private key and message, rather than sampled randomly for each signature. This design mitigates security risks associated with poor random number generators and enables reproducible signatures. However, improper deterministic nonce generation or design defects can systematically degrade the security of ECDSA, resulting in key leakage through public signatures or enabling efficient algebraic and lattice-based attacks. The topic intersects discrete logarithm theory, lattice problems, kleptography, formal verification, and implementation security.

## 1. Role of Nonces in ECDSA and Classic Attacks

In the classical ECDSA algorithm, a new random “nonce” $k$ is selected for each signature. The signing steps (in group of order $n$ and base point $G$) are:
1. Choose $k \in \{1, \dots, n-1\}$
2. Compute $R = kG$; set $r \equiv x$-coordinate$(R)\bmod n$
3. Compute $s = k^{-1}(H(m) + d r) \bmod n$ with $d$ the private key

This nonce must remain secret and unique for every signature. If $k$ is revealed or repeated, the secret key $d$ can be recovered immediately via
\[
d = (s \cdot k - H(m)) \cdot r^{-1} \bmod n
\]
as detailed in [1501.00447, 2504.07265]. Weaknesses in randomness may also leak partial bits of $k$, enabling lattice attacks to solve for $d$ via partial information, as in [2307.03979, 2504.07265].

Moreover, reusing $k$ across signatures or having relationships such as affine dependencies ($k_2 = a k_1 + b$) permits algebraic key recovery from as few as two signatures, as formalized in [2504.13737]:
\[
\text{priv} = \frac{a s_2 h_1 - h_2 s_1 + b s_1 s_2}{r_2 s_1 - a r_1 s_2} \bmod n
\]

## 2. Deterministic Nonce Generation: Goals, Methods, and Standards

Deterministic nonce generation seeks to eliminate the dependency on external, potentially unreliable random number sources by computing $k$ as a function of the private key and message:

- As recommended by RFC 6979 and EdDSA: $k = H(\text{private\_key} \| H(m))$ or $k = \text{HMAC}(\text{private\_key}, m)$ ([1902.10313]).
- This method ensures that, for a given message and key, $k$ is unique and reproducible, blocking accidental reuse and "subliminal channels"—hidden information leakage via nonce selection ([1508.06370]).
- Collision resistance and unpredictability of the hash/HMAC function are prerequisites; no information about the private key should be leaked through $k$ ([1902.10313, 2504.07265]).

Correct deterministic nonce generation binds the signature to both the message and secret key, strengthens the protocol against randomness failures, and is especially recommended for devices where cryptographic-grade random number generation is problematic ([1902.10313, 2505.23773]).

## 3. Dangers of Faulty or Biased Deterministic Nonce Implementations

While deterministic nonces mitigate certain classes of attacks, multiple studies document that implementation mistakes or inappropriate design can defeat these benefits:

- A critical example is the PuTTY SSH client with NIST P-521, which used a proprietary deterministic nonce scheme (denoted $k_\text{proto}$) computing $k = \text{SHA-512}(\text{digest} \| H(m))$, yielding a 512-bit value for a 521-bit curve ([2509.09331]). Since $k < 2^{512}$, the upper nine bits are always zero, introducing a deterministic bias.
- This allows attackers, from as few as 58 valid signatures—each giving a Hidden Number Problem instance with partially-known $k$—to solve for the private key via lattice reduction, as confirmed in the experimental findings acknowledged by PuTTY as CVE-2024-31497 ([2509.09331]).
- The attack structure is:
  - For each signature: $t \cdot a + b \equiv k \pmod q$, where $t = s^{-1} r$ and $b = s^{-1} H(m)$ are public, and $k$ is biased.
  - The system of equations with partially leaked $k$ is solved using lattice sieving (e.g., USVPPredSieve).

Imperfect hash-to-nonce mappings, output length mismatches, or poorly seeded deterministic derivations thus enable mass key recovery attacks.

## 4. Lattice and Algebraic Attacks on Partially Deterministic Nonces

Recent works ([2307.03979, 2509.09331]) reveal that even partial determinism or bit-sharing in nonces (e.g., multiple $k_i$ sharing upper or lower $\delta$ bits) drastically decreases entropy, allowing attackers to recover the private key with moderate effort:

- If $n$ signatures with ephemeral keys $k_0,\dots,k_n$ share $\delta$ bits, the difference $k_j - k_0$ is constrained, producing signature equations of the form:
  \[
  k_j + A_j \cdot a + B_j \equiv 0 \pmod q
  \]
  After eliminating shared bits and forming a reduced system, a lattice $L$ with dimension $n+1$ is constructed. The attacker locates short vectors representing the secret key via Kannan’s enumeration algorithm.
- The attack becomes polynomial-time if $n \cdot \delta \geq \ell$, where $\ell$ is the bit length of $q$ ([2307.03979]). For example, with $\delta=5$, only 58 signatures may be needed for complete break.
- Any fixed or predictable pattern across $k$ values—such as using a counter, linear recurrence, or truncating a hash output—exposes the implementation to such attacks ([2509.09331, 2307.03979, 2504.13737]).

For affine relations between nonces, algebraic attack requires only two signatures, with closed-form recovery of the private key ([2504.13737]).

## 5. Implementation, Formal Verification, and Practical Recommendations

Robust deterministic nonce implementation in ECDSA must satisfy:
- Strict compliance with bit-lengths and uniformity over the full interval $[1, n-1]$
- Use of non-malleable, collision-resistant cryptographic hash/HMAC functions ([1902.10313])
- Adoption of standards such as RFC 6979 in software and hardware, as opposed to improvised deterministic schemes ([2509.09331])
- For resource-constrained or verified environments, enforcement using abstract data types (ADTs) and linear types can guarantee compile-time single-use of nonces, as shown using Rust and similar languages ([2305.04138]). Linear types enforce that no nonce is reused, copied, or discarded; the compiler statically checks proper usage, representing advances in formal cryptographic correctness.

Potential countermeasures against covert channels or kleptographic attacks involving deterministic nonces may include device attestation, zero-knowledge proofs of proper nonce selection, or interactive protocols, though these introduce new verification and usability complexities ([1501.00447]).

## 6. Applications, Standards, and Impact in Real-World Systems

Deterministic nonces have become industry best practice in software wallets, security modules, and signature libraries, particularly where reliability of randomness is in question or stateless operation is desired ([1902.10313, 2505.23773, 1501.00447]). Their adoption is widespread in:
- Cryptocurrencies and blockchains (e.g., Bitcoin, Ethereum) ([1501.00447, 2505.23773])
- SSH clients and PKI tools ([2509.09331])
- Hardware wallets and resource-constrained devices ([1902.10313, 2305.04138])

Comparison with EdDSA reveals that schemes where deterministic nonce derivation is integral (e.g., EdDSA on Edwards curves) exhibit both security and efficiency advantages, including immunity to most classic ECDSA nonce attacks ([2505.23773]).

However, the continued emergence of vulnerabilities such as the PuTTY NIST P-521 bias (CVE-2024-31497) demonstrates that conformance to standards (RFC 6979) and comprehensive analysis against algebraic, lattice-based, and implementation vulnerabilities remain imperative. Missteps in deterministic nonce calculation are as dangerous as failures in random nonce generation.

## 7. Summary Table: Deterministic Nonce Security Properties

| Property                                    | Non-Deterministic Nonce         | Correct Deterministic Nonce            | Faulty Deterministic Nonce     |
|----------------------------------------------|---------------------------------|----------------------------------------|-------------------------------|
| Unpredictability                            | Depends on RNG quality          | Derived from hash/private key/message  | May be predictable            |
| Non-reuse                                   | Not enforced                    | Guaranteed (with proper design)        | May be violated if designed poorly |
| Resistance to kleptography/subliminal attack | None                            | Reduces attack surface                 | None                          |
| Lattice/algebraic attack resistance          | High with ideal RNG             | High if mapping is surjective and unbiased | Weak if bits leak/fixed      |
| Verification of proper generation            | Externally hard                 | Only private key holder can check      | Externally hard               |
| Implementation complexity                   | Lower                           | Higher (requires hash/HMAC discipline) | Misleadingly low              |

## References
- [1501.00447] Demonstrates kleptographic attacks via non-deterministic nonces and analyzes mitigation through deterministic generation.
- [1508.06370] Proposes nonce-generation in DSA to preclude subliminal channels; methods may be applied to ECDSA.
- [1902.10313] Surveys deterministic nonce use in the context of both security and performance.
- [2307.03979] Presents deterministic attacks on ECDSA with nonces sharing specific bits using efficient lattice techniques.
- [2504.07265] Reviews ECDSA cracking methods centered on nonce misuse, including deterministic and random-case weaknesses.
- [2504.13737] Formalizes affine relation-based algebraic key extraction in ECDSA even without direct nonce reuse.
- [2505.23773] Reports on practical ECDSA implementation and performance, with deterministic nonce awareness.
- [2509.09331] Details the PuTTY ECDSA deterministic nonce bias attack, culminating in private key recovery from 58 valid signatures and resulting in practical remediation.

Source: https://www.emergentmind.com/topics/deterministic-nonces-in-ecdsa