mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-11-29 19:38:25 +00:00
CH08: update RFC6979 text to describe BIP340 and synthentic nonces
This commit is contained in:
parent
5f4a8cfc66
commit
a28d4bb054
@ -364,6 +364,7 @@ See if you can decode Alice's serialized (DER-encoded) signature using
|
|||||||
this list. The important numbers are +R+ and +S+; the rest of the data
|
this list. The important numbers are +R+ and +S+; the rest of the data
|
||||||
is part of the DER encoding scheme.
|
is part of the DER encoding scheme.
|
||||||
|
|
||||||
|
[[nonce_warning]]
|
||||||
=== The Importance of Randomness in Signatures
|
=== The Importance of Randomness in Signatures
|
||||||
|
|
||||||
((("digital signatures", "randomness in")))As we saw in <<ecdsa_math>>,
|
((("digital signatures", "randomness in")))As we saw in <<ecdsa_math>>,
|
||||||
@ -392,15 +393,25 @@ generator.
|
|||||||
((("random numbers", "random number generation")))((("entropy", "random
|
((("random numbers", "random number generation")))((("entropy", "random
|
||||||
number generation")))((("deterministic initialization")))To avoid this
|
number generation")))((("deterministic initialization")))To avoid this
|
||||||
vulnerability, the industry best practice is to not generate _k_ with a
|
vulnerability, the industry best practice is to not generate _k_ with a
|
||||||
random-number generator seeded with entropy, but instead to use a
|
random-number generator seeded only with entropy, but instead to use a
|
||||||
deterministic-random process seeded with the transaction data itself.
|
process seeded in part with the transaction data itself.
|
||||||
This ensures that each transaction produces a different _k_. The
|
This ensures that each transaction produces a different _k_. The
|
||||||
industry-standard algorithm for deterministic initialization of _k_ is
|
industry-standard algorithm for deterministic initialization of _k_ for
|
||||||
defined in https://tools.ietf.org/html/rfc6979[RFC 6979], published by
|
ECDSA is defined in https://tools.ietf.org/html/rfc6979[RFC6979], published by
|
||||||
the Internet Engineering Task Force.
|
the Internet Engineering Task Force. For schnorr signatures, BIP340
|
||||||
|
recommends a default signing algorithm.
|
||||||
|
|
||||||
If you are implementing an algorithm to sign transactions in bitcoin,
|
BIP340 and RFC6979 can generate _k_ entirely deterministically, meaning the same
|
||||||
you _must_ use RFC 6979 or a similarly deterministic-random algorithm to
|
transaction data will always produce the same _k_. Many wallets do this
|
||||||
|
because it makes it easy to write tests to verify their safety-critical
|
||||||
|
signing code is producing _k_ values correctly. RFC6979 also allows
|
||||||
|
including additional data in the calculation. If that data is entropy,
|
||||||
|
then a different _k_ will be produced even if the exact same transaction
|
||||||
|
data is signed. This can increase protection against sidechannel and
|
||||||
|
fault-injection attacks.
|
||||||
|
|
||||||
|
If you are implementing an algorithm to sign transactions in Bitcoin,
|
||||||
|
you _must_ use BIP340, RFC6979, or a similar algorithm to
|
||||||
ensure you generate a different _k_ for each transaction.((("",
|
ensure you generate a different _k_ for each transaction.((("",
|
||||||
startref="Tdigsig06")))
|
startref="Tdigsig06")))
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user