summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuke Dashjr <luke_github1@dashjr.org>2020-02-19 22:44:04 +0000
committerGitHub <noreply@github.com>2020-02-19 22:44:04 +0000
commitfcce0e7656b7fef951d0a9a274f0e401eae0f5c7 (patch)
tree273c50b69b8ead45c03a046e76451983cb0aabf7
parent6fdf2eda61a5e643a6892e07e773b8e5befc930f (diff)
parentb4255dc83b2b8fde0c8e11152370c4df2da42c3e (diff)
downloadbips-fcce0e7656b7fef951d0a9a274f0e401eae0f5c7.tar.xz
Merge pull request #886 from jonasnick/synth-nonce
BIP 340: Recommend synthetic nonces and verifying signing output
-rw-r--r--bip-0340.mediawiki4
1 files changed, 3 insertions, 1 deletions
diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki
index 9e0a73e..2e05ef4 100644
--- a/bip-0340.mediawiki
+++ b/bip-0340.mediawiki
@@ -166,7 +166,9 @@ The algorithm ''Sign(sk, m)'' is defined as:
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.'''
-'''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. Adding RNG output may improve protection against [https://moderncrypto.org/mail-archive/curves/2017/000925.html fault injection attacks and side-channel attacks], and it is safe to add the output of a low-entropy RNG.
+'''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.
+
+'''Verifying the signing output''' To prevent random or attacker provoked computation errors, the signature can be verified with the verification algorithm defined below before leaving the signer. This prevents pubslishing invalid signatures which may leak information about the secret key. '''If the additional computational cost is not a concern, it is recommended to verify newly created signatures and reject them in case of failure.'''
'''Nonce exfiltration protection''' It is possible to strengthen the nonce generation algorithm using a second device. In this case, the second device contributes randomness which the actual signer provably incorporates into its nonce. This prevents certain attacks where the signer device is compromised and intentionally tries to leak the secret key through its nonce selection.