From a28d4bb054c794d1e108a416b8b4c85191a40508 Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Fri, 31 Mar 2023 08:20:36 -1000 Subject: [PATCH] CH08: update RFC6979 text to describe BIP340 and synthentic nonces --- chapters/signatures.adoc | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/chapters/signatures.adoc b/chapters/signatures.adoc index 0cf2cc4d..8ecee7d1 100644 --- a/chapters/signatures.adoc +++ b/chapters/signatures.adoc @@ -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 is part of the DER encoding scheme. +[[nonce_warning]] === The Importance of Randomness in Signatures ((("digital signatures", "randomness in")))As we saw in <>, @@ -392,15 +393,25 @@ generator. ((("random numbers", "random number generation")))((("entropy", "random number generation")))((("deterministic initialization")))To avoid this vulnerability, the industry best practice is to not generate _k_ with a -random-number generator seeded with entropy, but instead to use a -deterministic-random process seeded with the transaction data itself. +random-number generator seeded only with entropy, but instead to use a +process seeded in part with the transaction data itself. This ensures that each transaction produces a different _k_. The -industry-standard algorithm for deterministic initialization of _k_ is -defined in https://tools.ietf.org/html/rfc6979[RFC 6979], published by -the Internet Engineering Task Force. - -If you are implementing an algorithm to sign transactions in bitcoin, -you _must_ use RFC 6979 or a similarly deterministic-random algorithm to +industry-standard algorithm for deterministic initialization of _k_ for +ECDSA is defined in https://tools.ietf.org/html/rfc6979[RFC6979], published by +the Internet Engineering Task Force. For schnorr signatures, BIP340 +recommends a default signing algorithm. + +BIP340 and RFC6979 can generate _k_ entirely deterministically, meaning the same +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.((("", startref="Tdigsig06")))