notes about precomputed pubkey data

Author: ajtowns

bip-0340.mediawiki

@@ -128,6 +128,7 @@ The following conventions are used, with constants as defined for [https://www.s
 *** Fail if ''c &ne; y<sup>2</sup> mod p''.
 *** Return the unique point ''P'' such that ''x(P) = x'' and ''y(P) = y'', or fail if no such point exists.
 ** The function ''lift_x_even_y(x)'', where ''x'' is an integer in range ''0..p-1'', returns the point ''P'' for which ''x(P) = x'' and ''has_even_y(P)'', or fails if no such point exists. If such a point does exist, it is always equal to either ''lift_x_square_y(x)'' or ''-lift_x_square_y(x)'', which suggests implementing it in terms of ''lift_x_square_y'', and optionally negating the result.
+** The function ''extbytes(P)'', where ''P'' is a point, returns the compressed 33-byte encoding of P, that is ''0x02 || bytes(x(P))'' if ''has_even_y(P)'' or ''0x03 || bytes(x(P))'' otherwise.
 ** The function ''hash<sub>tag</sub>(x)'' where ''tag'' is a UTF-8 encoded tag name and ''x'' is a byte array returns the 32-byte hash ''SHA256(SHA256(tag) || SHA256(tag) || x)''.
 
 ==== Public Key Generation ====
@@ -154,8 +155,8 @@ The algorithm ''Sign(sk, m)'' is defined as:
 * Let ''d' = int(sk)''
 * Fail if ''d' = 0'' or ''d' &ge; n''
 * Let ''P = d'⋅G''
+* Let ''rand = hash<sub>BIP340/nonce</sub>(bytes(d') || extbytes(P) || m)''<ref>Including the [https://moderncrypto.org/mail-archive/curves/2020/001012.html public key as input to the nonce hash] helps ensure the robustness of the signing algorithm, preventing leakage of the secret key if the calculation of the public key ''P'' is performed incorrectly or maliciously, for example due to being left to the caller for performance reasons.</ref>.
 * Let ''d = d' '' if ''has_even_y(P)'', otherwise let ''d = n - d' ''.
-* Let ''rand = hash<sub>BIP340/nonce</sub>(bytes(d) || m)''.
 * Let ''k' = int(rand) mod n''<ref>Note that in general, taking a uniformly random 256-bit integer modulo the curve order will produce an unacceptably biased result. However, for the secp256k1 curve, the order is sufficiently close to ''2<sup>256</sup>'' that this bias is not observable (''1 - n / 2<sup>256</sup>'' is around ''1.27 * 2<sup>-128</sup>'').</ref>.
 * Fail if ''k' = 0''.
 * Let ''R = k'⋅G''.
@@ -167,7 +168,7 @@ 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.''' Nonce freshness with a derandomize nonce function implies that the same inputs must not be presented in another context. This can be most reliably accomplished by not reusing the same private key across different signing schemes. 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>BIP340/nonce</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.
+'''Synthetic nonces''' For instance when a RNG is available, RNG output can be appended to the input to ''hash<sub>BIP340/nonce</sub>''. This will change the corresponding line in the signing algorithm to ''rand = hash<sub>BIP340/nonce</sub>(bytes(d') || extbytes(P) || m || get_bytes_from_rng())'', where ''get_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. Note that adding up to 23 bytes comes with no performance penalty, while adding over 32 bytes serves no security purpose.
 
 '''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.'''
 
@@ -176,6 +177,8 @@ It should be noted that various alternative signing algorithms can be used to pr
 '''Multisignatures''' This signature scheme is compatible with various types of multisignature and threshold schemes such as [https://eprint.iacr.org/2018/068 MuSig], where a single public key requires holders of multiple secret keys to participate in signing (see Applications below).
 '''It is important to note that multisignature signing schemes in general are insecure with the ''rand'' generation from the default signing algorithm above (or any other deterministic method).'''
 
+'''Precomputed public key data''' For many uses the compressed 33-byte encoding of the public key may already be known, making it easy to evaluate ''extbytes(P)'', ''has_even_y(P)'' and ''bytes(P)''. As such, having signers supply this directly may be more efficient than calculating them from the secret key. However, if this optimization is used, signers must ensure the public key is correctly calculated and not taken from untrusted sources.
+
 ==== Verification ====
 
 Input: