Elaborate on default and alternative signing

1 files changed, 9 insertions, 4 deletions

diff --git a/bip-schnorr.mediawiki b/bip-schnorr.mediawiki
index 14f8610..44b2c84 100644
--- a/bip-schnorr.mediawiki
+++ b/bip-schnorr.mediawiki
@@ -129,7 +129,7 @@ Note that we use a very different public key format (32 bytes) than the ones use
 
 As an alternative to generating keys randomly, it is also possible and safe to repurpose existing key generation algorithms for ECDSA in a compatible way. The private keys constructed by such an algorithm can be used as ''sk'' directly. The public keys constructed by such an algorithm (assuming they use the 33-byte compressed encoding) need to be converted by dropping the first byte. Specifically, [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32] and schemes built on top of it remain usable.
 
-==== Signing ====
+==== Default Signing ====
 
 Input:
 * The secret key ''sk'': a 32-byte array
@@ -147,10 +147,15 @@ The algorithm ''Sign(sk, m)'' is defined as:
 * Let ''e = int(hash<sub>BIPSchnorr</sub>(bytes(R) || bytes(P) || m)) mod n''.
 * Return the signature ''bytes(R) || bytes((k + ed) mod n)''.
 
-'''Above deterministic derivation of ''R'' is designed specifically for this signing algorithm and may not be secure when used in other signature schemes.'''
-For example, using the same derivation in the MuSig multi-signature scheme leaks the secret key (see the [https://eprint.iacr.org/2018/068 MuSig paper] for details).
+==== Alternative Signing ====
 
-Note that this is not a ''unique signature'' scheme: while this algorithm will always produce the same signature for a given message and public key, ''k'' (and hence ''R'') may be generated in other ways (such as by a CSPRNG) producing a different, but still valid, signature.
+It should be noted that various alternative signing algorithms can be used to produce equally valid signatures. The algorithm in the previous section will always produce the same signature for a given message and public key, but the ''k'' value (and hence ''R'') may be generated in other ways, producing a different, but still valid, signature (in other words, it is not a ''unique'' signature scheme).
+
+'''Synthetic nonces''' When actual randomness is available, it can be appended to the input to ''hash<sub>BIPSchnorrDerive</sub>''s, after ''d'' and ''m''. This may improve protection against [https://moderncrypto.org/mail-archive/curves/2017/000925.html fault injection attacks].
+
+'''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 private key through its nonce selection.
+
+'''Multisignatures''' This signature scheme is compatible with various types of multisignature and threshold schemes, where a single public key requires holders of multiple private keys to participate in signing. One example is [https://eprint.iacr.org/2018/068 MuSig], which provides a way to aggregate multiple public keys into a single one, which all of the corresponding private keys need to sign for. It is important to note that multisignature signing schemes in general ''cannot'' be used with the nonce generation from the default signing algorithm above (or any deterministic nonce algorithm).
 
 ==== Verification ====