<p>The nonce <code>k</code> is supposed to be an <em>unpredictable</em> number in the range 1 to 115792089237316195423570985008687907852837564279074904382605163141518161494336, inclusive - one for each point on the curve except the point at infinity (note: <em>not</em> the size of the field, which is very slightly larger than the number of points on the curve).</p>
<p>One way of doing that is picking a uniformly random number in that range. This works, but makes your security crucially depend on having a good random number generator. This is a simple problem in theory, but in practice lots of problems do occur. Notable examples are the Playstation 3 codesigning system (which used a fixed constant as nonce), or a <a href="https://crypto.stackexchange.com/questions/9694/technical-details-of-attack-on-android-bitcoin-usage-of-securerandom">bug in Android</a> that in some cases resulted in applications generating the same sequence of &quot;random&quot; numbers.</p>
<p>The most common (and recommended) way today is using <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC 6979</a>. It essentially prescribes not using randomness at all at signing time, but computing the nonce using a (specific) hash function that takes the message and private key as input. Under reasonable assumptions, this is just as unpredictable to attackers (who don't know the private key) as using actual randomness, but avoids the engineering challenges with having access to a good RNG.</p>
<p>One word of warning: unpredictability is a very wide concept, and has lots of pitfalls. There are actual attacks against picking a nonce that is taken from a much smaller range, or against nonces that are picked in some related way. Don't try to be &quot;smart&quot; about it.</p>

CC BY-SA 4.0
2021-01-19T22:24:05.490Z
2021-01-19T22:24:05.490Z
2021-10-07T07:34:52.683Z
Pieter Wuille
<p>k is a random number (nonce). R is the x coordinate of the point that you get when multiplying k with G (the generator point). As a result, R is a number between 1 and N where N is the number you posted (115792089237316195423570985008687907852837564279074904382605163141518161494337 in decimal)</p>

CC BY-SA 4.0
2021-01-19T15:46:08.830Z
2021-01-19T15:46:08.830Z
Mike D
<p>I wonder about the random number used in signatures that result in R values ?
x coordinate R = G(k)
How is it created? Does it have a specific chars length?
Is there a specific random generator used, or restriction arguments?
I saw Python code online and found it is limited to max number of field points:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141</p>
<p>But as it is in hex format, I didn't know what does it mean.
So what is the max number to be used as it will processed as an integer?</p>

<signature><ecdsa><random>
How is the random number R for transaction signatures created?
user1610925
# How is the random number R for transaction signatures created?

(Asked by: username_0 on 2021-01-19)

I wonder about the random number used in signatures that result in R values ?
x coordinate R = G(k)
How is it created? Does it have a specific chars length?
Is there a specific random generator used, or restriction arguments?
I saw Python code online and found it is limited to max number of field points:
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141

But as it is in hex format, I didn't know what does it mean.
So what is the max number to be used as it will processed as an integer?

**Tags:** signature, ecdsa, random


---

## 2 answers

### Answer by username_1 on 2021-01-19. Score: 3

The nonce `k` is supposed to be an *unpredictable* number in the range 1 to 115792089237316195423570985008687907852837564279074904382605163141518161494336, inclusive - one for each point on the curve except the point at infinity (note: *not* the size of the field, which is very slightly larger than the number of points on the curve).

One way of doing that is picking a uniformly random number in that range. This works, but makes your security crucially depend on having a good random number generator. This is a simple problem in theory, but in practice lots of problems do occur. Notable examples are the Playstation 3 codesigning system (which used a fixed constant as nonce), or a [bug in Android](https://crypto.stackexchange.com/questions/9694/technical-details-of-attack-on-android-bitcoin-usage-of-securerandom) that in some cases resulted in applications generating the same sequence of "random" numbers.

The most common (and recommended) way today is using [RFC 6979](https://www.rfc-editor.org/rfc/rfc6979). It essentially prescribes not using randomness at all at signing time, but computing the nonce using a (specific) hash function that takes the message and private key as input. Under reasonable assumptions, this is just as unpredictable to attackers (who don't know the private key) as using actual randomness, but avoids the engineering challenges with having access to a good RNG.

One word of warning: unpredictability is a very wide concept, and has lots of pitfalls. There are actual attacks against picking a nonce that is taken from a much smaller range, or against nonces that are picked in some related way. Don't try to be "smart" about it.


---

### Answer by username_2 on 2021-01-19. Score: 0

k is a random number (nonce). R is the x coordinate of the point that you get when multiplying k with G (the generator point). As a result, R is a number between 1 and N where N is the number you posted (115792089237316195423570985008687907852837564279074904382605163141518161494337 in decimal)


---

