Adding deterministic signatures (RFC6979)?

[coder5876]

It seems that currently we are using a random k-value in the ECDSA algorithm:

https://github.com/ethereum/go-ethereum/blob/develop/crypto/secp256k1/secp256.go#L138

Is there interest in moving to a deterministic k-value using RFC6979?

Quick googling found this go library:

https://github.com/codahale/rfc6979

[obscuren]

Not at the moment. Is there a reason why you're asking? Are you working with a device which does not contain proper random number generators?

[obscuren]

Reference http://tools.ietf.org/html/rfc6979

[coder5876]

Deterministic signatures are nice in that you can confine your reliance of random numbers to only the generation of your private key(s). If you use dice to generate your private keys and have a deterministic signature algorithm then you can be sure that you are not exposed to potentially bad RNGs.

It's common to boot from a live CD or virtual machine when doing cold storage and those environments can suffer from low entropy in some cases.

Lastly it's nice to be able to do regression testing of your signature code (i.e. same signature every time), and/or comparing your signatures with signatures from other implementations.

[fjl]

Gotta agree with the last point about testing. Some of the network tests could be simpler if signatures where deterministic.

A potential downside is that tx resubmission would be harder. Right now you can force rebroadcasting of a transaction by signing it multiple times. Since the signature is random, you'll get a different tx hash every time.

[obscuren]

I can see deterministic k to be nice for 1 (and therefor 2), worth investigating further.

[mperklin]

I agree for 2 reasons:

1. RFC6979-compliant k values for digital signatures are more provably-unguessable than values retrieved from a CSPRNG. Problems with the CSPRNG call (like a library issue) could cause it to return 0 or 1 all the time, or return sequences of values across multiple calls that can be guessed (if it's always seeded with the same value). Calculating the value deterministically based on hashes of the data itself can be proven to be unguessable by ensuring the returned value conforms to the expected hash of the contents
2. It will allow all systems built on go-ethereum to reach the L3 requirement for 1.04 Key Usage in the CryptoCurrency Security Standard