8

Just given all the news about this topic lately (Android security flaw), I'm curious about WHERE and WHY the random number is used during the signing of a transaction.

I always thought a transaction was signed by just hashing the prev_out** and then encrypting that hash with the private key, so when it is published along side the public key it can be verified by other nodes.

**(maybe I need more clarity here too: is the ENTIRE previous transaction hashed at this point, or just one the input being used in the prev_out?)

Improve this question

3 Answers 3

Reset to default
2

As of 2017 most Bitcoin signing implementations implement RFC6979 and do not require randomness for signing. I wouldn't recommend using any that still does.

This approach derandomizes (ec)DSA by setting the secret nonce value k to a hash of the combination of the user's private key and the message. e.g. k = H(key || message). The particular hash in RFC6979 is a bit convoluted, but that's the basic idea. The ed25519 spec instructs implementers to derandomize in a similar way.

Improve this answer
3
  • Huh been long enough for this answer to change! Follow-up: If the R value is now deterministic, does that actually save space in the transaction? Or is there something else in its place?
    – pinhead
    Sep 12, 2018 at 16:37
  • @pinhead It does not have any advantages other than preventing signing the same thing and creating different signatures. Optionally, there are ways to force the length of the signatures to be lower than 72 while keeping the process deterministic: github.com/bitcoin/bitcoin/pull/13666
    – MCCCS
    Sep 12, 2018 at 16:58
  • Just because k (and by effect R) is computed by a deterministic process doesn't mean it's predictable by anyone else, if it were it would be insecure.
    – G. Maxwell
    Sep 12, 2018 at 17:03
8

This is a common misunderstanding. It just so happens that signing with RSA is the same as encrypting with the private key. But this is a quirk of the RSA algorithm. Bitcoin doesn't use RSA, it uses ECDSA. DSA is strictly a signature algorithm -- it has no encrypt operation at all.

The ECDSA signature operation, like the DSA signature algorithm, requires a random value in order to generate a signature. The signature consists of two derived parameters that can only be generated with the private key but that can be verified without it. The relationship between the derived parameters depends on the message, so the message cannot be altered.

Sadly, if the same random value is used for two signatures, the private key can be derived from the signature.

Improve this answer
4
  • 6
    Note that there is a safe way to generate the "random" number in a non-random way, namely by using a hash of message plus private key. This is even standardized in section 3.2 of RFC 6979. Unfortunately, it was only very recently added to OpenSSL, so it's not very portable for programs to use yet.
    – Pieter Wuille
    Aug 21, 2013 at 21:21
  • @PieterWuille So simply hash the data first then sign only and this potential problem is negated? Thank you so much in advance!
    – user5107
    Jan 1, 2014 at 23:29
  • 2
    @Gracchus You're already doing that. You still have a problem if you sign two different hashes with the same key. The solution is to use a deterministic scheme to generate a number that is "effectively random" for purposes of the ECDSA signature but chosen in such a way that you cannot accidentally reveal your private key.
    – David Schwartz
    Jan 2, 2014 at 13:59
  • @DavidSchwartz Thank you David Schwartz! I read the RFC, and I think I now understand.
    – user5107
    Jan 2, 2014 at 16:19
1

The random number is needed as a parameter for the calculation of the signature in the ECDSA system. If you reuse the nonce, to recover the private key is just matter of solving

Key=((r * modpow((s1 - s2), p - 2, p) * ((m1 * s2) - (m2 * s1)) % p

Example attack:

R=6819641642398093696120236467967538361543858578256722584730163952555838220871
S1=5111069398017465712735164463809304352000044522184731945150717785434666956473
M1=4834837306435966184874350434501389872155834069808640791394730023708942795899
S2=31133511789966193434473156682648022965280901634950536313584626906865295404159
M2=108808786585075507407446857551522706228868950080801424952567576192808212665067

Gives the result 35027840177330064405683178523079910253772859809146826320797401203281604260438 Which represents the key for 1FaapwdwYVVBiV6Qvkis88c2KHPoxX1Jb1

References

https://strm.sh/post/bitcoin-transaction-nonce-reuse/

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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