<blockquote>
<p><strong>What's the length of k (random number), in bytes, bits?</strong></p>
</blockquote>
<p>256 bits.</p>
<p>The number <em>k</em> (also called the nonce) in ECDSA must be an unpredictable value, indistinguishable from uniformly random among the set of all valid private keys. For secp256k1, that range is from <em>0x1</em> to <em>0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140</em>, inclusive. Since the lower bound is so close to 0, and the upper bound is so close to <em>2<sup>256</sup></em>, just using a uniform 256-bit value will always be valid k, except with negligible probability.</p>
<blockquote>
<p><strong>Has anyone successfully replicated, mimicked the k for signatures, where k is not known?</strong></p>
</blockquote>
<p>If you can successfully guess the <em>k</em> value used in a signature, you can compute its private key. For correctly-functioning wallet software, this is hopefully impossible to third parties.</p>
<blockquote>
<p><strong>Has anyone successfully &quot;mined&quot;, or brute forced a k for signatures?</strong></p>
</blockquote>
<p>Brute forcing will only work against badly-generated nonces that are chosen from a very small range, which is probably fairly rare. There are other misuses of nonce creation however, which have occurred in practice, and have been exploited.</p>
<p>One of them is reusing the same nonce value twice with the same private key, for different messages. When identified, this allows computing the private key as well. This was used to attack the PlayStation 3 security (where every signature used the same <em>k</em> value).</p>
<p>More subtle nonce crimes, and a fairly advanced attack against them, is described in <a href="https://eprint.iacr.org/2019/023.pdf" rel="nofollow noreferrer">this paper</a>.</p>
<blockquote>
<p>Is it possible to brute force the k by randomly generating random number with the function/algorithm being implemented in bitcoin core? (I suppose it is RFC-6979 or something)</p>
</blockquote>
<p>RFC6979 describes a derandomized nonce generation algorithm. Somewhat simplified, what it suggests is akin to using <em>Hash(private_key || message)</em> as nonce. This has the property that it is unpredictable to third parties (since they don't know the private key), and will never result in reuse for distinct messages under the same private key.</p>
<p>When nonces are generated this way, and you don't know the private key, trying to brute force is hopeless. Computing the private key from the public key using an algorithm like <a href="https://en.wikipedia.org/wiki/Pollard%27s_rho_algorithm_for_logarithms" rel="nofollow noreferrer">Pollard's Rho</a>, and then solving for the nonce, would be many orders of magnitude faster than trying to brute force the nonce directly.</p>

CC BY-SA 4.0
2022-08-18T09:41:29.580Z
Thank you for the explanation!
Maltoon Yezi
CC BY-SA 4.0
2022-08-16T14:42:34.477Z
2022-08-16T15:34:42.750Z
2022-08-16T15:34:42.750Z
Pieter Wuille
<p>One of the component of making of SECP256K1 signatures, is a random number that is later multiplied by the generator point in order to be used in further computations.</p>
<p>If we imagine that k - is the random nonce number and G - is the generator point, then:</p>
<p><a href="https://i.sstatic.net/vy1bn.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/vy1bn.png" alt="From Programming Bitcoin by Jimmy Song" /></a></p>
<p><strong>What's the length of k (random number), in bytes, bits?</strong></p>
<p>However, I am trying to find the answer in the <a href="https://github.com/bitcoin-core/secp256k1/blob/master/examples/ecdsa.c" rel="nofollow noreferrer">Bitcoin core source code</a>, but it's kind of hard to read and could find an answer to it there.</p>
<pre><code>    /* Generate an ECDSA signature `noncefp` and `ndata` 
allows you to pass a * custom nonce function, passing `NULL` 
will use the RFC-6979 safe default. * Signing with a valid context, 
verified secret key * and the default nonce function should never fail. */
    
    return_val = secp256k1_ecdsa_sign(ctx, &amp;sig, msg_hash, seckey, NULL, NULL);
    
    assert(return_val);
</code></pre>
<p>I am not sure where is k located in the code.</p>
<p>Also curious about other things:</p>
<p><strong>Has anyone successfully replicated, mimicked the k for signatures, where k is not known?</strong></p>
<p><strong>Has anyone successfully &quot;mined&quot;, or brute forced a k for signatures?</strong></p>
<p><strong>Is it possible to brute force the k by randomly generating random number with the function/algorithm being implemented in bitcoin core?</strong> (I suppose it is RFC-6979 or something)</p>

<bitcoin-core><ecdsa><secp256k1><c>
Questions about generating a random number for ECDSA
Maltoon Yezi
# Questions about generating a random number for ECDSA

(Asked by: username_0 on 2022-08-16)

One of the component of making of SECP256K1 signatures, is a random number that is later multiplied by the generator point in order to be used in further computations.

If we imagine that k - is the random nonce number and G - is the generator point, then:

[![From Programming Bitcoin by Jimmy Song](https://i.sstatic.net/vy1bn.png)](https://i.sstatic.net/vy1bn.png)

**What's the length of k (random number), in bytes, bits?**

However, I am trying to find the answer in the [Bitcoin core source code](https://github.com/bitcoin-core/secp256k1/blob/master/examples/ecdsa.c), but it's kind of hard to read and could find an answer to it there.

```
    /* Generate an ECDSA signature `noncefp` and `ndata` 
allows you to pass a * custom nonce function, passing `NULL` 
will use the RFC-6979 safe default. * Signing with a valid context, 
verified secret key * and the default nonce function should never fail. */
    
    return_val = secp256k1_ecdsa_sign(ctx, &sig, msg_hash, seckey, NULL, NULL);
    
    assert(return_val);

```

I am not sure where is k located in the code.

Also curious about other things:

**Has anyone successfully replicated, mimicked the k for signatures, where k is not known?**

**Has anyone successfully "mined", or brute forced a k for signatures?**

**Is it possible to brute force the k by randomly generating random number with the function/algorithm being implemented in bitcoin core?** (I suppose it is RFC-6979 or something)

**Tags:** bitcoin-core, ecdsa, secp256k1, c


---

## 1 answers

### Answer by username_1 on 2022-08-16. Score: 4 | Accepted answer

> **What's the length of k (random number), in bytes, bits?**

256 bits.

The number *k* (also called the nonce) in ECDSA must be an unpredictable value, indistinguishable from uniformly random among the set of all valid private keys. For secp256k1, that range is from *0x1* to *0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140*, inclusive. Since the lower bound is so close to 0, and the upper bound is so close to *2256*, just using a uniform 256-bit value will always be valid k, except with negligible probability.

> **Has anyone successfully replicated, mimicked the k for signatures, where k is not known?**

If you can successfully guess the *k* value used in a signature, you can compute its private key. For correctly-functioning wallet software, this is hopefully impossible to third parties.

> **Has anyone successfully "mined", or brute forced a k for signatures?**

Brute forcing will only work against badly-generated nonces that are chosen from a very small range, which is probably fairly rare. There are other misuses of nonce creation however, which have occurred in practice, and have been exploited.

One of them is reusing the same nonce value twice with the same private key, for different messages. When identified, this allows computing the private key as well. This was used to attack the PlayStation 3 security (where every signature used the same *k* value).

More subtle nonce crimes, and a fairly advanced attack against them, is described in [this paper](https://eprint.iacr.org/2019/023.pdf).

> Is it possible to brute force the k by randomly generating random number with the function/algorithm being implemented in bitcoin core? (I suppose it is RFC-6979 or something)

RFC6979 describes a derandomized nonce generation algorithm. Somewhat simplified, what it suggests is akin to using *Hash(private\_key || message)* as nonce. This has the property that it is unpredictable to third parties (since they don't know the private key), and will never result in reuse for distinct messages under the same private key.

When nonces are generated this way, and you don't know the private key, trying to brute force is hopeless. Computing the private key from the public key using an algorithm like [Pollard's Rho](https://en.wikipedia.org/wiki/Pollard%27s_rho_algorithm_for_logarithms), and then solving for the nonce, would be many orders of magnitude faster than trying to brute force the nonce directly.

> **Comments:**
> **username_0**: Thank you for the explanation!  

---

