<p>The secp256k1 library uses <a href="https://www.rfc-editor.org/rfc/rfc6979" rel="nofollow noreferrer">RFC6979</a> to generate deterministic nonce values (<code>k</code>). It essentially takes the hash of both the private key and the message being signed in order to get <code>k</code>. This means that signing the same message with the same private key multiple times will always result in the same signature.</p>
<p>Other libraries may not do this. For example, ECDSA only requires that <code>k</code> be a random integer (or rather that <code>k</code> is indistinguishable from random). Therefore, some libraries will simply generate a random <code>k</code> and use that. RFC 6979 is another way to generate a <code>k</code> that is indistinguishable from random, assuming that the hash function used is pseudorandom (meaning its output is indistinguishable from random). The hash function used by Secp256k1 is HMAC-SHA256 which is considered secure.</p>

CC BY-SA 4.0
2019-01-18T17:33:18.977Z
Thanks
So basically other libraries that do not deterministically generate k but use a random k should still be able to produce a valid signature that would be accepted by the network?
MandelDuck
CC BY-SA 4.0
2019-01-18T17:51:04.573Z
@MandelDuck Correct. It's not possible to enforce that signatures are deterministic (if you could figure out whether they were, you could also learn the private key), so ECDSA (and all EC based signatures schemes like Schnorr and Ed25519) does not have deterministic signatures. Individual implementations can choose to be deterministic, but that's a purely local unobservable implementation detail.
Pieter Wuille
CC BY-SA 4.0
2019-01-18T17:57:07.663Z
thanks guys thats good to know, makes perfect sense
MandelDuck
CC BY-SA 4.0
2019-09-24T20:18:22.620Z
@MandelDuck Please mark Andrew's answer as a valid answer so this will get marked as answered.
elichai2
CC BY-SA 4.0
2019-01-18T17:09:01.437Z
2022-02-18T16:32:14.027Z
2022-02-18T16:32:14.027Z
Ava Chow
<p>I noticed in bitcoin when using the <code>tiny-secp256k1</code> library to sign the signature for a signature hash of an input; the signature is always the same.</p>
<p>However, the signature is always different in other ECDSA-Secp256k1 libraries. (I'm using one by nordic semiconductors.)</p>
<p>Do I misunderstand something? Is there a difference in the signature algorithms?</p>
<p>I read something about randomly and deterministically calculating the <code>k</code> value; should it matter if it is random or not? Or is there possibly extra encoding done after the signature hash is signed in Bitcoin Secp256k1?</p>

<signature><ecdsa><secp256k1>
tiny-secp256k1 and ECDSA signing determinism
MandelDuck
# tiny-secp256k1 and ECDSA signing determinism

(Asked by: username_0 on 2019-01-18)

I noticed in bitcoin when using the `tiny-secp256k1` library to sign the signature for a signature hash of an input; the signature is always the same.

However, the signature is always different in other ECDSA-Secp256k1 libraries. (I'm using one by nordic semiconductors.)

Do I misunderstand something? Is there a difference in the signature algorithms?

I read something about randomly and deterministically calculating the `k` value; should it matter if it is random or not? Or is there possibly extra encoding done after the signature hash is signed in Bitcoin Secp256k1?

**Tags:** signature, ecdsa, secp256k1


---

## 1 answers

### Answer by username_1 on 2019-01-18. Score: 6

The secp256k1 library uses [RFC6979](https://www.rfc-editor.org/rfc/rfc6979) to generate deterministic nonce values (`k`). It essentially takes the hash of both the private key and the message being signed in order to get `k`. This means that signing the same message with the same private key multiple times will always result in the same signature.

Other libraries may not do this. For example, ECDSA only requires that `k` be a random integer (or rather that `k` is indistinguishable from random). Therefore, some libraries will simply generate a random `k` and use that. RFC 6979 is another way to generate a `k` that is indistinguishable from random, assuming that the hash function used is pseudorandom (meaning its output is indistinguishable from random). The hash function used by Secp256k1 is HMAC-SHA256 which is considered secure.

> **Comments:**
> **username_0**: Thanks So basically other libraries that do not deterministically generate k but use a random k should still be able to produce a valid signature that would be accepted by the network?  
> **username_2**: @username_0 Correct. It's not possible to enforce that signatures are deterministic (if you could figure out whether they were, you could also learn the private key), so ECDSA (and all EC based signatures schemes like Schnorr and Ed25519) does not have deterministic signatures. Individual implementations can choose to be deterministic, but that's a purely local unobservable implementation detail.  
> **username_0**: thanks guys thats good to know, makes perfect sense  
> **username_3**: @username_0 Please mark Andrew's answer as a valid answer so this will get marked as answered.  

---

