11

Generating random number k in elliptic curve is crucial and in any transactions signature in Bitcoin, random number k is required to compute a point k*G. If this k is chosen not randomly, it instantly leaks the private key.
Therefore, they came up with an idea of deterministic generation of ECDSA which is described in RFC6979. Basically they concatenate the private key with the hashed message and use an HMAC function and generate a pseudo random k.
This method seems simple and easy.

  • Does it introduce any overhead?
  • If yes, is this overhead negligible?

Or generally is there any inefficiencies or problem with this method and why do we still see non-deterministic implementation of ECDSA?

Community
  • 1
abeikverdi
  • 864
  • 8
  • 22

1 Answers1

11

Not any serious efficiency concerns. Signing is done fairly infrequently for any particular client (only a few signatures per transaction usually). While possible that the signing might take slightly longer to generate the k value, it would not be noticeable, especially considering how infrequently it is used by any one particular client. It's the verification of all the signatures that is the CPU bottleneck for block verification in bitcoin, because all full nodes have to verify the signatures of all the transactions on the network, and this takes the same time regardless of how the k parameter was chosen.

Gregory Maxwell made a comment about the use of deterministic k values here:

The primary arguments in most spaces against derandomizing DSA are FIPS conformance (irrelevant for us) and reasonable concerns about the risks of using a (less) reviewed cryptographic construct. With widespread motion towards derandomized DSA this latter concern is less of an issue.

The new libsecp256k1 library by Pieter Wuille actually uses deterministic generation of k.

Also note that one of the key benefits of using this construction is that you need not worry about a weakness in your PRNG being exploited in the signing process. For example, signing different pieces of data with the same k value instantly leaks your private key. A similar attack can also be exploited if the PRNG is weak enough to determine the relationship between different k values used when signing the same piece of data. Since the k is deterministically generated from the data you are signing (and the private key), these concerns about the PRNG are no longer as relevant, as you will always produce the same signature for the same piece of data. This also makes writing ECDSA unit tests easier.

Community
  • 1
morsecoder
  • 14,168
  • 2
  • 42
  • 94
  • As you mentioned the verification process is the same and adding couple of extra HMAC computation to the client side doesn't really affect the signature process. – abeikverdi Feb 20 '15 at 06:27
  • Signing the same data twice with different 'k' values is safe. – amaclin Feb 20 '15 at 08:03
  • 4
    @adaclin Only if an attacker cannot determine the relation between the two k values used. If for example one k is known to be equal to the other plus one, it instantly leaks your private key. – Pieter Wuille Feb 20 '15 at 08:51
  • 1
    @PieterWuille Thanks, I have updated my answer. I had confused the different-ks-same-data attack with the different-data-same-ks attack mentioned here. – morsecoder Feb 20 '15 at 13:07
  • @abeikverdi Actually, generating a nonce using RFC6979 with SHA256 requires 22 invocations of the SHA256 compression function, which takes in the order of 10% of the whole signing time. – Pieter Wuille Feb 20 '15 at 19:52
  • @PieterWuille Can you illuminate me? Dont we just concatenate the private key and the hashed message as the HMAC nonce? – abeikverdi Feb 21 '15 at 02:41
  • @abeikverdi Read RFC6979 and try to implement it, you'll see. – Pieter Wuille Feb 21 '15 at 08:29
  • @PieterWuille I have already read RFC6979. Never tried to implement that though. Is this 10% overhead time that you are referring to, you personal experience? or its scientific? – abeikverdi Feb 22 '15 at 06:19
  • I benchmarked it. Can't get more scientific than that. – Pieter Wuille Feb 22 '15 at 14:42
  • @StephenM347 Wouldn't this RFC 6979 generates the same k twice? HMAC_DBGA(private key d || H(m)) generates the same k for the same hashed message since the private key is constant. Doesn't it? Isn't that a problem? – abeikverdi Feb 22 '15 at 15:51
  • @abeikverdi, Not really, that's exactly why it's useful is because it produces the same signature for the same data. It only uses the same k twice for the same message. It's only when you sign different data with the same k value that it leaks your private key. Using the same k for the same data doesn't give any new information. – morsecoder Feb 22 '15 at 17:04
  • @StephenM347 the data that you are referring which is the hashed message is the hash of transaction? – abeikverdi Feb 22 '15 at 17:11
  • @abeikverdi, essentially, yes, the data being signed is a hash of the transaction which has been cleared of all inputs (you don't sign other signatures). There's one more little nuance, that the previous scriptPubKey of the output being spent is inserted in the scriptSig before double SHA256 hashing. – morsecoder Feb 22 '15 at 17:19
  • @StephenM347 Thanks a lot! I totally got it now! – abeikverdi Feb 22 '15 at 17:27