Disclaimer

This is work in progress.

Threshold Signatures

Unforgeability

\(t-1\) malicious peers
cannot produce
a valid signature.

Robustness

 \(t\) honest peers
can produce
a valid signature.

\(t\)-of-\(n\)

\(n\)-of-\(n\): Multisignatures

Why Threshold/Multi Signatures?

  • 2-of-2: Payment channels
  • 2-of-2: two-factor authentication
  • 3-of-6: Bitfinex cold wallet
  • 11-of-15: Liquid watchmen
  • ...

Threshold signatures should look like ordinary signatures!

Goal

Taproot

\textit{pk} = g^{x+H(g^x,\textit{script})}

Key-path spending

  • produce signature, valid under \(pk\)

Script-path spending

  • reveal \(g^x\) and \(\textit{script}\)
  • fulfill script
  • script not revealed at all
  • looks like ordinary spend

Schnorr Signatures

\( \textsf{Sign}(\textit{sk} = x, \textit{pk} = g^x, m) \)

\( r \leftarrow \$ \)
\( R = g^r \)
\( c = H(\textit{pk}, R, m) \)
\( s = x\cdot c + r \)
\( \text{return}\ (R, s) \)

\( \textsf{Verify}(\textit{pk} = X, (R, s), m) \)

\(\phantom{r \leftarrow \$ }\)
\(\phantom{ R = g^r }\)
\( c = H(\textit{pk}, R, m) \)
\(\text{return}\ g^s = X^c \cdot R \)
 

\(\textit{sk}=x\)

\(\textit{pk}=g^x\)

Draft for Bitcoin Improvement Proposal (BIP)

https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki

 

  • by Pieter Wuille and many more
  • Full technical specification
  • Detailed design rationale
  • Reference code and test vectors

We need more eyeballs!

Naive Multisignatures

\begin{matrix} x\!\!\!\! &=\!\!\!\! &x_1\!\!\!\! &+\!\!\!\! &x_2\!\!\!\! &+\!\!\!\! &\dotsc\!\!\!\! &+\!\!\!\! &x_n\\[1ex] r\!\!\!\! &=\!\!\!\! &r_1\!\!\!\! &+\!\!\!\! &r_2\!\!\!\! &+\!\!\!\! &\dotsc\!\!\!\! &+\!\!\!\! &r_n \end{matrix}
\dotsm

\(X_1=g^{x_1}\)
\(R_1 = g^{r_1}\)

\(X_2=g^{x_2}\)
\(R_2 = g^{r_2}\)

\(X_3=g^{x_3}\)
\(R_3 = g^{r_3}\)

\dotsm

Full Solutions

From Multi To Threshold

Secret Sharing (simplified)

Threshold Secret Sharing

\(a\)

\(a_1\)

\(a_2\)

\(a_3\)

2-of-3

\(a\)

Distributed Key Generation (DKG)

\begin{matrix} x\!\!\!\! &=\!\!\!\! &x_1\!\!\!\! &+\!\!\!\! &x_2\!\!\!\! &+\!\!\!\! &x_3 \end{matrix}

DKG

DKG for Secret Key (\(n=3\), simplified)

DKG for Key and Nonce

\begin{matrix} x\!\!\!\! &=\!\!\!\! &x_1\!\!\!\! &+\!\!\!\! &x_2\!\!\!\! &+\!\!\!\! &x_3 \end{matrix}
\begin{matrix} r\!\!\!\! &=\!\!\!\! &r_1\!\!\!\! &+\!\!\!\! &r_2\!\!\!\! &+\!\!\!\! &r_3 \end{matrix}

\(O(f)\) rounds

\(O(1)\) rounds

DKG for Key and Nonce

DKG for Secret Key and Nonce (\(n=3\), simplified)

History of DKG for DLog

  • Pedersen (1991):
    Here is a DKG scheme for DLog. It uses Feldman's VSS.
  • Everybody:
    Cool, let's use it.
  • Gennaro, Jarecki, Krawcyz, Rabin (1999):
    The attacker can bias the key.
    Here is a better DKG scheme using Pedersen's VSS.
  • Gennaro, Jarecki, Krawcyz, Rabin (2002):
    The 1991 scheme is good enough  for Schnorr threshold signatures.
     

What's the Point?

Why do these Schemes Fail in Practice?

Issue #1: Trust Assumption

\(t - 1 < \frac{n}{2}\)

(Honest majority)

Counterexample

Unforgeability

5 malicious peers
cannot produce
a valid signature.

Robustness

6 honest peers
can produce
a valid signature.

6-of-9

Assumption Ignores Good Cases

worst
case

better
case

Drop the Assumption?

Security Reduction

No,
reduction relies on honest majority
to extract secrets of the attacker.

Idea: Use other commitments in verifiable secret sharing.

Issue #2: Broadcast Channel

Broadcast Channel

  • Reasonable assumption for robustness
  • Unreasonable assumption for unforgeability

Fail gracefully:
Give up liveness but never give up safety!

Attack on Unforgeability

reconstruct \(r_1, r_2\)

reconstruct \(r_3, r_4\)

1

2

3

4

4

3

1

2

Attack on Unforgeability

Malicious broadcast channel learns
the nonce \(r = r_1 + r_2 + r_3 + r_4\) and
the signature \((R, s)\).

Combined secret key is \(x=(s - r)/c.\)

Malicious vs. Offline

Idea: Reconstruct only partial signature \(s_i\).

Theory vs. Practice

Just because a peer appears offline,
we cannot simply reconstruct his secrets in public!

Wish List

  • Produces ordinary Schnorr signatures
  • No restrictions on \(t\)
  • Unforgeability against malicious broadcast
  • Robustness in \(O(1)\) rounds
  • Reasonable message complexity
  • Secure in parallel sessions

Bonus List

  • Asynchrony
  • Deterministic nonces
  • Look at setup algorithm
  • Adaptive security
  • Accountability

Don’t Trust. Verify.