Threshold Signature Scheme (TSS)

The secure generation of secret shares is the most critical phase. A compromised or malicious dealer during Distributed Key Generation (DKG) can bias the resulting key or learn other parties' shares. Secure Multi-Party Computation (MPC) protocols for DKG must be verifiable to ensure no single party can reconstruct the master private key or predict the final signature.

Attackers may attempt to disrupt or manipulate the signing protocol itself. Common threats include:

• Rushing Attacks: Where an adversary sends its share last, after seeing others, to manipulate the final signature.
• Forgery via Malicious Reconstruction: If the protocol is not robust, a subset of malicious participants can reconstruct a valid signature for a message they did not all agree to sign.
• Denial-of-Service (DoS): A single malicious participant can refuse to provide their share, blocking all signatures.

TSS implementations are vulnerable to side-channel attacks that leak secret information through timing, power consumption, or electromagnetic emissions during computation. Physical attacks on the devices holding secret shares (HSMs, mobile phones) are also a risk. Countermeasures include constant-time algorithms, hardware security modules (HSMs), and secure enclaves.

Long-lived secret shares are vulnerable to gradual compromise. A proactive secret sharing scheme periodically refreshes shares without changing the master public key. This limits the window for an attacker to collect enough shares over time. Without this, an attacker who slowly compromises participants could eventually reach the threshold.

Flaws in the cryptographic library or protocol implementation can be catastrophic. Examples include:

• Incorrect zero-knowledge proofs during DKG.
• Weak or non-standard elliptic curve parameters.
• Bugs in the signature aggregation logic. These are single points of failure that can compromise the entire system, underscoring the need for formal verification and extensive auditing.

TSS manages cryptographic signing, not business logic. A separate authorization layer (e.g., multi-sig smart contract, policy server) is required to determine which transactions are valid to sign. If this layer is compromised, or if the TSS participants collude to sign an unauthorized transaction, funds can be stolen. The security of the signing ceremony and participant authentication is paramount.

A foundational secret sharing scheme often confused with TSS. In SSS, a single private key is split into shares and distributed. To reconstruct the key, a threshold of shares must be combined. Crucially, the full key is reassembled in one place during signing. TSS is superior for signing as the key is never reconstructed; signatures are computed distributively, keeping the master key non-existent and eliminating the reconstruction attack vector.

The underlying cryptographic primitive that TSS protocols implement distributively. Common algorithms include:

• ECDSA (Elliptic Curve Digital Signature Algorithm): Used by Bitcoin and Ethereum.
• EdDSA (Edwards-curve Digital Signature Algorithm): Used by protocols like Solana and Zcash. A TSS protocol defines how multiple parties can collaboratively perform the signing operations of these algorithms, producing a signature that is indistinguishable from one created by a single key holder.

The core access structure of a TSS, defined by parameters (t, n). In a t-of-n scheme:

• n is the total number of participating parties or key shares.
• t is the threshold, the minimum number of parties required to produce a valid signature. This provides flexibility for security and availability. For example, a 2-of-3 setup for a wallet allows signing if any two of three key holders agree, balancing security against the loss of a single share.

A critical initialization phase for many TSS implementations. Instead of one party generating and splitting a key (as in SSS), the parties run a DKG protocol to jointly create the public key and their individual secret shares. No party ever knows the full private key, which only exists as a distributed secret. This enhances security from the start, preventing a single point of compromise during setup.

Blockchain-native multisig (e.g., Bitcoin's OP_CHECKMULTISIG, Ethereum's Gnosis Safe) and TSS-based wallets solve similar problems but differ fundamentally:

• On-chain vs. Off-chain: Multisig logic is enforced on-chain via smart contracts or scripts; TSS signing occurs off-chain, producing a single signature.
• Privacy & Cost: A TSS transaction looks like a regular single-signer transaction, offering privacy and lower gas fees. A multisig transaction reveals the policy (e.g., 2-of-3) on-chain and requires more data, increasing cost.