I've noticed that in many Bitcoin wallet implementations, as well as other blockchains, deterministic ECDSA signatures are being used (generally based on RFC 6979).

There seems to be some benefits to this:

  • Testing would be easier, as you can have known inputs and outputs.
  • There is no need for a good source of randomness at the time of signature generation
  • Some blockchain operations might be easier if signatures produce consistent output for the same data (e.g. identifying if the same blocks have been signed before)

I'm working in a constrained hardware environment where I don't have access to a deterministic ECDSA implementation, but I do have good entropy. Are there any security risks in participating in a blockchain network without deterministic signatures?

  • 1
    $\begingroup$ Do you mean that you have access to a nondeterministic ECDSA implementation that itself has a good source of entropy? If you can choose the random nonce, or the seed from which it is generated, then you can use that to do deterministic ECDSA. But if you really don't have a choice in the matter, and you're really confident in the uniformity of the ECDSA hardware's choice of nonces, then I don't think there's a security risk to it. $\endgroup$ – Squeamish Ossifrage Aug 10 '17 at 15:20
  • 1
    $\begingroup$ For anybody else deterministic and non-deterministic ECDSA signatures are indistinguishable. And before deterministic ECDSA was a thing, everybody used the non-deterministic ones, so besides the points you mentioned you don't lose anything... $\endgroup$ – SEJPM Aug 10 '17 at 18:37
  • $\begingroup$ @SqueamishOssifrage I was probably unnecessarily vague in my question - I'm working with an HSM that has good entropy but no support for deterministic signatures in its firmware. Per your comment and SEJPM's, I'll crack on :-) $\endgroup$ – Duncan Jones Aug 11 '17 at 6:52

No, you'll be fine (most likely).

DSA (the base of ECDSA) has been around since at least 1993 (when FIPS 186 was released). Much like with ECDSA you also need a $k$-value for DSA for each signature. From what I know, RFC 6979 (August 2014, first draft in march 2011) was the first general standard and Ed25519 (special case of EdDSA now, september 2011 (PDF)) the first specific DSA variant to use deterministic $k$-generation. So essentially people used random $k$ values for nearly 20 years and issues came up only when people failed to ensure the randomness of the value (by re-using it or using a bad RNG). However this does not apply to you as your HSM will take care of that. So you'll be just as fine as all the people were before we had deterministic (EC)DSA.

The only drawbacks are essentially those that you listed in your question, the first two of which don't matter if you trust your HSM and the last one you can't do anything about.

Also note that a deterministic (EC)DSA signature is indistinguishable from a non-deterministic one except if you have two signatures of the same data.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.