Blind Schnorr signatures

schnorrblind.md

Blind Schnorr signatures

Requester has a message-hash m that they want to be signed by pubkey P that is owned by Signer (who knows P = xG for private key x and generator G).

The following is a direct adaptation of Matthew Green's blind scheme adapted for the specific case of bip-schnorr elliptic curve signatures (including the sign-flip factor) and has been used in the wild (for internal protocol message signing, not for transaction signing) since late 2019 in the BCH CashFusion protocol.

Symbols:

• R R' P G are elliptic curve points. Additive convention is used.
• n is the curve order.
• a b e e' i j k s s' x are integers mod n.
• c is -1 or +1.

Protocol:

• Signer generates R = kG for random k.
• ⇦ Signer sends R to Requester.
• Requester calculates: R' = c (R + aG + bP) for random a and b. The signflip factor c is chosen as -1 or +1 to suit the Schnorr symmetry-breaking scheme if present (i.e. check on Legendre symbol in case of bip-schnorr).
• Requester calculates: e' = Hash(R'.x || ser(P) || m) mod n.
• Requester calculates: e = ce' + b mod n.
• ⇨ Requester sends e to Signer.
• Signer calculates s = k + ex mod n.
• ⇦ Signer sends s to Requester.
• Requester calculates s' = c(s+a) mod n.
• Requester now possesses a valid signature (R', s') on m, from P, since s'G = R' + e'P.

Obtaining blind signatures from any related key

Requester can manipulate the blinding factors to instead obtain a signature from public key iP + jG for any integers i or j, in other words, they can get a signature from any multiplicatively or additively related key, i.e., just as if it was signed by the private key ix + j.

Depending on the situation this may be harmless, useful, or an exploit. For this reason it is advised to completely avoid using BIP32 unhardened public keys for blind signatures, unless one deliberately wants & understands this property. The Signer has no idea this is happening, as apparent by the fact that the communications and Signer steps remain unchanged (italicized below).

• Signer generates R = kG for random k.
• ⇦ Signer sends R to Requester.
• Requester calculates: R' = c (R + aG + bP) for random a and b. The signflip factor c is chosen as -1 or +1 to suit the Schnorr symmetry-breaking scheme if present (i.e. check on Legendre symbol in case of bip-schnorr).
• Requester calculates: e' = Hash(R'.x || ser(iP+jG) || m) mod n.
• Requester calculates: e = ce'i + b mod n. ((inserted factor i))
• ⇨ Requester sends e to Signer.
• Signer calculates s = k + ex mod n.
• ⇦ Signer sends s to Requester.
• Requester calculates s' = c(s+a) + e'j mod n. ((added term e'j))
• Requester now possesses a valid signature (R', s') on m, from iP+jG, since s'G = R' + e'(iP+jG).

To derive this, start at the basic protocol and substitute iP+jG in place of P, and forget the prior equations for e and for s'. Then find the values of e and s' that are necessary to make the validation equation hold true.

s'G = R' + e'(iP+jG)
    = cR + caG + cbP + e'iP + e'jG                      (sub in value of R')
    = csG - ceP + caG + cbP + e'iP + e'jG               (use R=sG-eP)
  0 = (cs + ca + e'j - s') G + (-ce + cb + e'i) P       (collect factors of G and P separately)

The coefficients of G and P must each be 0 since Requester doesn't know x, so we have both:
  0 = cs + ca + e'j - s',   and,   0 = -ce + cb + e'i