BIP-340: Stress that secret key should be fresh and if not then RFC6979 shouldn't be used

1 files changed, 2 insertions, 2 deletions

diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki
index d2f92db..2fe3481 100644
--- a/bip-0340.mediawiki
+++ b/bip-0340.mediawiki
@@ -132,7 +132,7 @@ The following conventions are used, with constants as defined for [https://www.s
 ==== Public Key Generation ====
 
 Input:
-* The secret key ''sk'': a 32-byte array, generated uniformly at random
+* The secret key ''sk'': a 32-byte array, freshly generated uniformly at random
 
 The algorithm ''PubKey(sk)'' is defined as:
 * Let ''d = int(sk)''.
@@ -164,7 +164,7 @@ The algorithm ''Sign(sk, m)'' is defined as:
 
 ==== Alternative Signing ====
 
-It should be noted that various alternative signing algorithms can be used to produce equally valid signatures. The algorithm in the previous section is deterministic, i.e., it will always produce the same signature for a given message and secret key. This method does not need a random number generator (RNG) at signing time and is thus trivially robust against failures of RNGs. Alternatively the 32-byte ''rand'' value may be generated in other ways, producing a different but still valid signature (in other words, this is not a ''unique'' signature scheme). '''No matter which method is used to generate the ''rand'' value, the value must be a fresh uniformly random 32-byte string which is not even partially predictable for the attacker.'''
+It should be noted that various alternative signing algorithms can be used to produce equally valid signatures. The algorithm in the previous section is deterministic, i.e., it will always produce the same signature for a given message and secret key. This method does not need a random number generator (RNG) at signing time and is thus trivially robust against failures of RNGs. Alternatively the 32-byte ''rand'' value may be generated in other ways, producing a different but still valid signature (in other words, this is not a ''unique'' signature scheme). '''No matter which method is used to generate the ''rand'' value, the value must be a fresh uniformly random 32-byte string which is not even partially predictable for the attacker.''' Freshness implies that reusing a secret key in different signature schemes is discouraged. For example, if the ''rand'' value was computed as per RFC6979 and the same secret key is used in deterministic ECDSA with RFC6979, the signatures can leak the secret key through nonce reuse.
 
 '''Synthetic nonces''' For instance when a RNG is available, 32 bytes of RNG output can be appended to the input to ''hash<sub>BIPSchnorrDerive</sub>''. This will change the corresponding line in the signing algorithm to ''rand = hash<sub>BIPSchnorrDerive</sub>(bytes(d) || m || get_32_bytes_from_rng())'', where ''get_32_bytes_from_rng()'' is the call to the RNG. It is safe to add the output of a low-entropy RNG. Adding high-entropy RNG output may improve protection against [https://moderncrypto.org/mail-archive/curves/2017/000925.html fault injection attacks and side-channel attacks]. Therefore, '''synthetic nonces are recommended in settings where these attacks are a concern''' - in particular on offline signing devices.