diff options
author | Luke Dashjr <luke_github1@dashjr.org> | 2020-02-28 17:08:51 +0000 |
---|---|---|
committer | GitHub <noreply@github.com> | 2020-02-28 17:08:51 +0000 |
commit | ce4da9e3eec7c7df81dea105cc2ea4155f8bef47 (patch) | |
tree | f63b5136483d3c0838ea45ba4099f8ae7032491e /bip-0340.mediawiki | |
parent | 995a500032f56d916714a182ae123cfa64a81487 (diff) | |
parent | 4b18c45e74c1e13993cd049d302abd3ab1f00761 (diff) | |
download | bips-ce4da9e3eec7c7df81dea105cc2ea4155f8bef47.tar.xz |
Merge pull request #892 from CaptJakk/master
Typo in BIP340
Diffstat (limited to 'bip-0340.mediawiki')
-rw-r--r-- | bip-0340.mediawiki | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki index 9fcc113..d2f92db 100644 --- a/bip-0340.mediawiki +++ b/bip-0340.mediawiki @@ -168,7 +168,7 @@ It should be noted that various alternative signing algorithms can be used to pr '''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.''' +'''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 publishing 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. |