user3667: 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?) 

user39087: 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/

user52021: 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. 

user85: 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.

3667: <p>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.</p>

<p>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.</p>

<p>**(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?) </p>
 39087: <p>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</p>

<pre><code>Key=((r * modpow((s1 - s2), p - 2, p) * ((m1 * s2) - (m2 * s1)) % p
</code></pre>

<p>Example attack:</p>

<pre><code>R=6819641642398093696120236467967538361543858578256722584730163952555838220871
S1=5111069398017465712735164463809304352000044522184731945150717785434666956473
M1=4834837306435966184874350434501389872155834069808640791394730023708942795899
S2=31133511789966193434473156682648022965280901634950536313584626906865295404159
M2=108808786585075507407446857551522706228868950080801424952567576192808212665067
</code></pre>

<p>Gives the result <code>35027840177330064405683178523079910253772859809146826320797401203281604260438</code>
Which represents the key for <code>1FaapwdwYVVBiV6Qvkis88c2KHPoxX1Jb1</code></p>

<h2>References</h2>

<p><a href="https://strm.sh/post/bitcoin-transaction-nonce-reuse/" rel="nofollow noreferrer">https://strm.sh/post/bitcoin-transaction-nonce-reuse/</a></p>
 52021: <p>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.</p>

<p>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. </p>
 85: <p>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.</p>

<p>The <a href="http://en.wikipedia.org/wiki/Digital_Signature_Algorithm#Signing">ECDSA signature operation</a>, 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.</p>

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