Attacks on Threshold Schemes: Part 1

Threshold cryptography looks bulletproof on paper. You distribute trust across multiple parties, require a minimum threshold to reconstruct secrets or produce signatures, and suddenly you've got resilience against single points of failure. The math checks out, the security proofs are elegant, and the protocols feel rock-solid.

Then you ship to production and things start breaking. Sometimes it's a missing validation check that nobody thought mattered. Sometimes it's a subtle ambiguity in how data gets encoded. The gap between "provably secure threshold scheme" and "production-ready implementation that won't get your users rekt" is wider than most people realize.

This post walks through real attacks on real threshold systems, the kind that security auditors have actually found in the wild. The goal isn't to scare you away from threshold schemes, they're still one of the best tools we have for distributed trust. The goal is to give you a practical checklist of what actually goes wrong, so you can audit your own implementation with clear eyes before it hits mainnet.

Pedersen DKG: Wrong-Degree Polynomial Attack

During an audit of Frost, Trail of Bits discovered an interesting vulnerability. The participants do not check the length of the polynomial coefficients, meaning the polynomial can be of much higher degree which would result in an inability to recover the key.

Pedersen's distributed key generation builds on Feldman's verifiable secret sharing, which extends Shamir's scheme by letting participants verify their shares without a trusted dealer. The basic flow: each party $P_i$ generates a random degree-$t$ polynomial $p_i(x) = a_{i,0} + a_{i,1}x + \cdots + a_{i,t}x^t$ where $a_{i,0}$ is their secret contribution. They publish commitments to each coefficient:

$$A_{i,0} = g^{a_{i,0}}, \quad A_{i,1} = g^{a_{i,1}}, \quad \ldots, \quad A_{i,t} = g^{a_{i,t}}$$

Then $P_i$ sends the evaluation $s_{i,j} = p_i(j)$ privately to each party $P_j$. Recipient $P_j$ verifies their share by checking:

$$g^{s_{i,j}} \stackrel{?}{=} \prod_{k=0}^{t} A_{i,k}^{j^k}$$

To form the final shared secret, each party $P_j$ sums all shares they received: $s_j = \sum_{i=1}^{n} s_{i,j}$. The collective polynomial is $p(x) = \sum_{i=1}^{n} p_i(x)$, which has degree $t$ and secret $s = p(0) = \sum_{i=1}^{n} a_{i,0}$. Any $t+1$ parties can recover $s$ via Lagrange interpolation.

The Attack

During an audit of FROST implementations, they discovered that many don't validate the length of the commitment vector. A malicious $P_i$ can submit a polynomial of degree $T > t$, say, degree $2t$ or even degree $n$. Since the final polynomial degree is the maximum of all input degrees, this silently raises the reconstruction threshold from $t+1$ to $T+1$.

If $T \geq n$, the secret becomes unrecoverable: no subset of parties can reconstruct it, even with everyone's cooperation. All shares are now locked, and any funds controlled by that key are permanently lost. Even if $T < n$, signature attempts with only $t+1$ parties will mysteriously fail, and implementations may blame honest participants for the failure.

The fix is trivial: check that each commitment vector has exactly $t+1$ elements. Trail of Bits found ten vulnerable implementations, including multiple FROST variants and GG18/GG20 libraries.

Missing Discrete Log Check in MtA

The Multiplicative-to-Additive (MtA) protocol is common in threshold schemes, it converts shares of a product $a \times b$ into additive shares $\alpha + \beta \equiv a \times b \pmod{q}$. Most implementations include zero-knowledge proofs to ensure parties behave honestly, but these proofs require careful setup.

The Setup

Each party generates auxiliary parameters for the ZK proofs:

• An RSA modulus $\tilde{N} = pq$ (factorization kept secret)
• Two group elements $h_1, h_2 \in \mathbb{Z}_{\tilde{N}}^*$ that should be unrelated (no known discrete log between them)

The commitment in the proof typically looks like $z = h_1^m h_2^{\rho} \mod \tilde{N}$, where $m$ is the value being proven and $\rho$ is blinding randomness. The security relies on the prover not knowing $\log_{h_1}(h_2)$, if they did, they could break the proof's soundness.

The Attack

The protocol should include a check that $h_1$ and $h_2$ generate the same cyclic subgroup and that their discrete log relation is unknown. But many implementations skip this verification entirely, trusting the sender to have generated them correctly.

An attacker exploits this by setting $h_2 = 1$. Now the commitment collapses:

$$z = h_1^m h_2^{\rho} = h_1^m \cdot 1^{\rho} = h_1^m \mod \tilde{N}$$

The blinding term vanishes, and $z$ directly reveals $h_1^m$. To extract $m$, the attacker has two options:

Option 1: Integer logarithm Choose $\tilde{N}$ extremely large so that computing discrete logs in $\mathbb{Z}_{\tilde{N}}^*$ becomes as hard as computing integer logarithms, which is trivial with standard algorithms.

Option 2: Pohlig-Hellman Choose $\tilde{N}$ as a product of many small primes: $\tilde{N} = p_1 p_2 \cdots p_k$ where each $p_i$ is small. The order of $\mathbb{Z}_{\tilde{N}}^*$ is then $\phi(\tilde{N}) = (p_1-1)(p_2-1)\cdots(p_k-1)$, which is smooth. Using Pohlig-Hellman, the attacker computes $m \bmod (p_i-1)$ for each factor (fast, since the factors are small), then reconstructs $m$ via the Chinese Remainder Theorem.

Either way, the attacker recovers $m$ and breaks the proof. This leaks the victim's secret value that was supposed to be protected by the zero-knowledge property.

This vulnerability was discovered in Binance's TSS library and described in the paper "Attacking Threshold Wallets".

The Fix: The sender should prove in zero-knowledge that $\log_{h_1}(h_2)$ is unknown and that $h_1$ and $h_2$ generate the same cyclic group. Additionally, the Paillier modulus $\tilde{N}$ must be proven to be the product of two primes of sufficient size.

BitGo Wallet: Missing Proof of Knowledge

Proofs of knowledge aren't just formalities, they're critical checkpoints that prevent malicious parties from feeding garbage into the protocol. The BitGo wallet vulnerability shows what happens when you skip them.

The Protocol

BitGo's TSS implementation follows the GG18 key generation protocol, which has three phases:

1. Commit: Each player $P_i$ selects a secret key share $u_i$ and broadcasts:

   • A commitment $g^{u_i}$ to their secret
   • A Paillier public key $E_i$ with modulus $N_i$

2. Reveal & Share: Each player opens their commitment (reveals $u_i$), then performs Feldman VSS to distribute shares of $u_i$. The final shared secret is $x = \sum u_i$, with public key $y = g^x = \prod g^{u_i}$. Each player ends up with a share $x_i$ such that any threshold subset can reconstruct $x$.

3. Prove: Each player should prove in zero-knowledge:

   • Knowledge of their share $x_i$ (proof of knowledge)
   • That their Paillier modulus $N_i = p_i q_i$ is the product of exactly two primes (biprimality proof)

BitGo's implementation skipped phase 3 entirely. No proofs. Just trust.

The Attack

The attacker exploits the missing biprimality proof by choosing a malicious Paillier modulus $N = pq$ where $q = 2p + 1$. This is a safe prime construction, but with a twist: the multiplicative group $\mathbb{Z}_N^*$ has a special structure that leaks information. The attacker also picks any square $V \in \mathbb{Z}_N^*$ (say, $V = 4$) and broadcasts $(N, V)$ as their Paillier parameters.

During the protocol, an honest party $P_j$ (the victim) will encrypt their share under the attacker's key. They send:

$$C = V^x \cdot \text{Enc}(\beta) \mod N^2$$

where $x$ is the victim's secret share and $\beta$ is some randomness. The Paillier encryption is $\text{Enc}(\beta) = (1+N)^\beta r^N$ for random $r$.

Now the attacker reduces $C$ modulo $q$:

$$C \equiv V^x \cdot (1+N)^\beta r^N \equiv V^x \cdot r^N \pmod{q}$$

The $(1+N)^\beta$ term vanishes mod $q$ since $N \equiv 0 \pmod{q}$. Next, the attacker computes:

$$C^{p+1} \equiv (V^x r^N)^{p+1} \equiv V^{x(p+1)} r^{N(p+1)} \pmod{q}$$

Here's the key observation: in $\mathbb{Z}_q^*$, the order is $q-1 = 2p$. Every square (like $V$) has order dividing $p$, and $r^{pq} \equiv 1 \pmod{q}$ by Fermat's little theorem. So:

$$C^{p+1} \equiv V^{x(p+1)} \equiv V^x \pmod{q}$$

because $V^p \equiv 1 \pmod{q}$.

Now the attacker has $V^x \bmod q$. Since $q = 2p+1$ is small enough (the attacker chose it), they can brute-force the discrete log to recover $x \bmod q$.

Scaling the Attack

If $q$ is too large for a single brute-force, the attacker can use a product of many such pairs: $N = p_1q_1 \cdots p_{16}q_{16}$ where each $q_i = 2p_i + 1$ and each $p_i$ is small (say, 16 bits). They run the attack in parallel to recover $x \bmod q_i$ for each $i$, then use the Chinese Remainder Theorem to reconstruct $x$.

With 16 such pairs and 16-bit primes, the attacker recovers a 256-bit secret share in a few hours on commodity hardware. Once they have one share, they can sign arbitrary transactions unilaterally, completely defeating the threshold property.

This vulnerability was discovered by Fireblocks during a security analysis of BitGo's implementation and described in their blog post.

The Fix: Include the missing proofs. The Paillier modulus $N_i$ must be proven biprime (product of exactly two large primes), and each player must prove knowledge of their share $x_i$.

Not So Secret Factorization

Sometimes the attack isn't a missing check, it's that the implementation gives the prover knowledge they were never supposed to have. This vulnerability in a two-party ECDSA reshare protocol shows how knowing "too much" can be weaponized.

The Reshare Protocol

Key resharing is standard practice in production TSS wallets, you periodically rotate shares to limit exposure. The protocol looks simple enough:

1. Alice generates a fresh Paillier keypair $(n', sk')$
2. Alice sends a new ciphertext $c' = \text{Enc}(x_1')$ under her new key, where $x_1' = x_1 + r$ (her old share plus randomness)
3. Alice proves in zero-knowledge that $c'$ encrypts a value linearly related to her old ciphertext $c = \text{Enc}(x_1)$, i.e., $c' = c \oplus \text{Enc}(r)$ (using Paillier homomorphism)

Bob receives $c'$, verifies the proof, and updates his own share to $x_2' = x_2 - r$. The combined secret remains unchanged: $x_1' + x_2' = (x_1 + r) + (x_2 - r) = x_1 + x_2 = x$.

The Problem

The zero-knowledge proof for step 3 requires two moduli $n_1$ and $n_2$. The security assumption from the literature: "Let $n_1$ be a large composite number whose factorization is unknown by Alice and Bob, and $n_2$ be another large number, prime or composite whose factorization is known or unknown by Alice."

But in this implementation, Alice knows both factorizations, she generated both Paillier keys herself. She can now turn the reshare protocol into an oracle that leaks Bob's share bit by bit.

The Attack

Alice manipulates her new share to be $x_1'' = x_1' + kq$ where $k$ is chosen so that:

$$|n_i| - q \leq x_1 + kq < |n_i|$$

Bob doesn't detect anything wrong. He combines Alice's malicious share with his rotated share:

$$x_{12} = x_1'' + x_2' = (x_1' + kq) + (x_2 - r) = x_1 + x_2 + kq$$

When they run the signing protocol, Bob sends his partial signature to Alice. Alice decrypts the combined result and reduces it mod $q$. But during Paillier decryption, a reduction mod $n_i$ happens first. This is where the oracle kicks in:

• If $x_2 < n_i - kq - x_1$, then the mod $n_i$ reduction doesn't wrap around. The final signature verifies correctly.
• If $x_2 \geq n_i - kq - x_1$, then the mod $n_i$ reduction changes the value. The signature fails verification.

Alice just learned whether $x_2$ crosses a specific threshold. She records the result.

Extracting the Secret

By repeating this reshare-and-sign cycle with different values of $k$ and $n_i$, Alice narrows down Bob's share. Each successful or failed signature reveals one bit of information about $x_2$. With enough iterations (proportional to the bit length of $x_2$), Alice reconstructs Bob's entire share.

Once she has both $x_1$ and $x_2$, the threshold property collapses. Alice can sign any transaction unilaterally.

This issue was found during an analysis of a production two-party ECDSA implementation and is detailed in the paper "Attacking Threshold Wallets".

The Fix

The ZK proof must enforce that Alice doesn't know the factorization of $n_1$. Better yet, the library maintainers did what made most sense: they replaced the vulnerable reshare with the full two-party key generation protocol. Alice and Bob run a coin flip to refresh their shares and repeat all ZK proofs from DKG. It's slower, but it's correct, and it doesn't give Alice an oracle.

Ambiguous Hash Encoding

Fiat-Shamir is supposed to be straightforward: hash the transcript, use the output as your challenge. But if you're sloppy about how you encode the transcript, you hand the prover a degree of freedom they're not supposed to have.

The Flaw

When converting an interactive proof to non-interactive via Fiat-Shamir, you need to hash multiple values together, group elements, integers, commitments, etc. A naive approach: concatenate everything with a delimiter.

$$H(\alpha_1 ,|, D ,|, \alpha_2 ,|, D ,|, \ldots ,|, D ,|, \alpha_n)$$

where $D$ is some delimiter byte sequence (say, || or a null byte). The problem: during the "opening" phase, there's ambiguity. Is the first element $\alpha_1$, or is it $\alpha_1 ,|, D ,|, \alpha_2$? If the prover can shift boundaries around, they can manipulate which parts of the input get interpreted as which values, without changing the hash output.

Example: Discrete Log Proof

Consider a simple discrete log proof (like the one used in threshold signature ZK subprotocols):

1. Prover commits: Pick random $\rho$, send $\alpha = h^\rho$ (or $\alpha = h^\rho g^{-1}$ depending on strategy)
2. Challenge: Compute challenge bits $c = H(g, h, N, \alpha_1, \alpha_2, \ldots, \alpha_\lambda)$ where $\lambda$ is the number of repetitions
3. Response: For each iteration $i$, send $\tau_i = \rho_i + c_i \cdot \text{secret}$

The proof is repeated $\lambda$ times to amplify soundness. Each iteration contributes one challenge bit $c_i$.

The Attack

The attacker (playing the prover) wants to forge a proof for $\log_h g$ without knowing it. Here's how:

1. Guess the challenge bits: The attacker anticipates how many 1 bits will appear in the challenge $c = (c_1, \ldots, c_\lambda)$. Say they guess $k$ ones.

2. Craft ambiguous commitments: For each iteration $i$, the attacker prepares two possible $\alpha$ values:

   • $\alpha^1 = h^{\rho_i}$ if they plan to answer as if $c_i = 0$
   • $\alpha^2 = h^{\rho_i} g^{-1}$ if they plan to answer as if $c_i = 1$

3. Commit ambiguously: The attacker sends a byte stream that looks like $\alpha_1 ,|, D ,|, \alpha_2 ,|, D ,|, \ldots$ but can be parsed in multiple ways. Specifically, they construct it so that after hashing, they can "shuffle" which bytes belong to which $\alpha_i$ based on the resulting challenge bits.

4. Reinterpret after seeing the challenge: Once the hash outputs challenge bits $c_i$, the attacker retroactively decides how to parse their commitment. If $c_i = 0$, they claim they sent $\alpha^1 = h^{\rho_i}$. If $c_i = 1$, they claim they sent $\alpha^2 = h^{\rho_i} g^{-1}$. In both cases, they respond with $\tau_i = \rho_i$.

5. Verification passes: The verifier checks $h^{\tau_i} \stackrel{?}{=} \alpha_i \cdot g^{c_i}$. If the attacker correctly shuffled:

   • For $c_i = 0$: $h^{\rho_i} = \alpha^1$ ✓
   • For $c_i = 1$: $h^{\rho_i} = \alpha^2 \cdot g = (h^{\rho_i} g^{-1}) \cdot g$ ✓

The key insight: as long as the number of $a$ tokens in the byte stream matches what the hash function expects (regardless of how they're interpreted), the hash remains unchanged. The attacker rearranges $(\alpha, \alpha, \ldots, \alpha, \beta, \beta, \ldots, \beta)$ to match the challenge bits, and it all verifies.

This vulnerability (the α-shuffle attack) was discovered by Verichains on Binance's tss-lib, Multichain and a few others. The affected implementations and full technical details are described in their blog post.

The Fix Use unambiguous encoding. Don't just concatenate with delimiters. Modern protocols like FROST and CGGMP20 mandate specific serialization formats precisely to avoid this. Don't roll your own concatenation scheme.

Not Enough Soundness

Remember that discrete log proof we just talked about? It gets repeated $\lambda$ times, and the soundness error is $2^{-\lambda}$. To forge a proof without knowing the discrete log, an attacker needs to guess all $\lambda$ challenge bits correctly, probability $2^{-\lambda}$. If you want 128-bit security, you need $\lambda = 128$ repetitions. Straightforward.

The Attack

Some production implementations used $\lambda = 80$, or even $\lambda = 32$. At $\lambda = 80$, an attacker has a $2^{-80}$ chance of forging a proof, feasible with enough compute. At $\lambda = 32$, it's trivial.

The TSSHOCK paper found libraries that just... set the parameter too low. No clever cryptographic insight needed. Just brute-force the challenge space until you get lucky.

This attack (c-guess) was also discovered by Verichains in Multichain's implementation.

The Fix: Set $\lambda \geq 128$. Read the security proof. Use the parameters the paper recommends, not whatever seemed "good enough" during implementation.

Non-Existent Inverse

So you read the previous section and thought, "let's just use a larger challenge space instead of repeating the protocol 128 times, sample $c$ from all 256-bit strings instead of just ${0,1}$." Sounds reasonable. One round, bigger challenge, same security. Except it doesn't work in composite-order groups.

The Flaw

In the standard dlnproof, you're proving knowledge of $\log_h g$ in a group of order $\text{ord}(g)$. The protocol:

1. Prover commits $\alpha = g^\rho$ for random $\rho$
2. Challenge $c \in {0, 1, \ldots, 2^{256}-1}$ (large range, single round)
3. Prover responds $\tau = \rho + c \cdot \text{secret}$

The verifier checks $g^\tau \stackrel{?}{=} \alpha \cdot h^c$. This works fine in prime-order groups. But in composite-order groups (like $\mathbb{Z}_{\tilde{N}}^*$ for an RSA modulus $\tilde{N}$), things break.

The Attack

Suppose the attacker wants to forge a proof for $\log_h g$ when this discrete log doesn't exist. Specifically, let $h = g^e$ where $e$ is a small divisor of $\text{ord}(g)$ and $2 \mid \text{ord}(g)$: $\log_h g = \frac{1}{e}$ doesn't exist in $\mathbb{Z}_{\text{ord}(g)}$ because $e$ has no multiplicative inverse modulo $\text{ord}(g)$ (since $\gcd(e, \text{ord}(g)) \neq 1$).

The attacker proceeds as follows:

1. Brute-force random $\rho$ values until the resulting challenge $c = H(\ldots)$ is divisible by $e$. Since $c$ is 256 bits, the probability that $e \mid c$ is roughly $\frac{1}{e}$. If $e$ is small (say, 32 bits), this takes negligible time.
2. Once $e \mid c$, the attacker constructs the proof: $(\alpha, \tau) = (g^\rho \bmod \tilde{N}, \rho + \frac{c}{e})$.
3. Verification:

$$g^\tau = g^{\rho + c/e} = g^\rho \cdot g^{c/e} = \alpha \cdot (g^e)^{c/e} = \alpha \cdot h^c$$

The proof passes, even though the attacker doesn't know $\log_h g$.

Why It Works In a prime-order group, $\frac{c}{e}$ wouldn't be well-defined unless $e$ has an inverse. But in composite-order groups with a small factor $e$ dividing the order, the attacker can "split" the challenge by that factor and forge proofs for non-existent discrete logs.

This is the third attack (c-split) in Verichains’ TSSHOCK suite and affects Axelar, ZenGo and. ING. Full details can be found in their article.

The Fix Either:

• Stick with prime-order groups (like the elliptic curve subgroup, not $\mathbb{Z}_{\tilde{N}}^*$)
• Use the multi-round version with binary challenges (80–128 rounds)
• If you must use composite-order groups with large challenges, ensure the group order is prime or prove that all relevant discrete logs exist before running the protocol

This is why modern threshold ECDSA protocols work over elliptic curves (prime-order subgroups) for signature generation, and only use RSA groups (composite order) carefully in auxiliary ZK proofs with proper parameter checks.

Small Paillier Attack

Even when range proofs are included, implementation bugs can still cause problems. This attack exploits a missing validation on the Paillier modulus size itself.

The Setup

In MtAwc with range proofs, Bob (the party with secret $b$) sends a zero-knowledge proof that includes:

1. A challenge $e \in \mathbb{Z}_q$ (computed via Fiat-Shamir)
2. A random blinding value $\gamma \in \mathbb{Z}_N^*$ (where $N$ is Alice's Paillier public key)
3. A proof element $t_1 = e\beta' + \gamma$ (computed over the integers), where $\beta'$ is Bob's secret from the MtA protocol

The proof is supposed to hide $\beta'$. The security relies on $\gamma$ being large enough to mask $\beta'$ when divided by $e$.

The Attack

The attacker (Alice) generates a Paillier modulus $N$ that's slightly smaller than $2^{256}$. If the protocol doesn't explicitly validate the key size, this gets through.

Now look at what happens when Bob computes $t_1 = e\beta' + \gamma$:

$$\frac{t_1}{e} = \beta' + \frac{\gamma}{e}$$

Normally, $\gamma \in \mathbb{Z}_N^*$ with $N \approx 2^{2048}$ and $e \approx 2^{256}$, so $\frac{\gamma}{e}$ is large enough to hide $\beta'$ when divided by $e$. But if $N \approx q \approx 2^{256}$, then $\gamma$ is only about $2^{256}$ bits. Now:

• With probability $\frac{1}{2}$, we have $\frac{\gamma}{e} < 1$ (i.e., $\gamma < e$)
• With probability $1 - 2^{-16}$, we have $\frac{\gamma}{e} < 2^{15}$ (i.e., less than 15 bits)

This means $\beta' \approx \lfloor \frac{t_1}{e} \rfloor$ with high probability. The blinding almost vanishes.

Extracting the Secret

Alice also knows that with $N \approx q$, if she sets her input $a = 1$ in the MtA protocol, the decrypted value $\alpha' = b + \beta'$ (over the integers) falls into one of two ranges:

1. If $b + \beta' < N$: No modular reduction, so $\alpha = b + \beta'$
2. If $b + \beta' \in [N, 2N)$: Reduction occurs, so $\alpha = b + \beta' - N$

Alice knows $\alpha$ (she decrypted it) and can approximate $\beta' \approx \lfloor \frac{t_1}{e} \rfloor$ from the proof. She tries several candidates:

$$\beta \in {\lfloor \tfrac{t_1}{e} \rfloor \bmod q, , \lfloor \tfrac{t_1}{e} \rfloor - 1 \bmod q, , \lfloor \tfrac{t_1}{e} \rfloor - 2 \bmod q, \ldots}$$

For each candidate $\beta$, she computes two possibilities for Bob's secret $b$ :

1. $b^{(1)} = \alpha - \beta \bmod q$ (assuming no wraparound)
2. $b^{(2)} = \alpha - \beta + N \bmod q$ (assuming wraparound)

She checks which one is correct by verifying $g^{b^{(1)}} \stackrel{?}{=} g^b$ or $g^{b^{(2)}} \stackrel{?}{=} g^b$, where $g^b$ is Bob's public key (known to everyone).

One of these will match. Alice has recovered Bob's secret $b$ in a single signature.

Why It Works

Two bugs compound:

1. Wrong range for $\gamma$: The ZK proof spec says $\gamma$ should be sampled from $\mathbb{Z}_{q^2 N}$, not $\mathbb{Z}_N^*$. Using $\mathbb{Z}_N^*$ breaks honest-verifier zero-knowledge, dividing by $e$ leaks bits of $\beta'$ regardless of Paillier modulus size.
2. Missing Paillier size check: Even with the wrong range, if $N$ were properly validated to be $\geq 2^{2048}$, the leakage would be negligible. But without validation, Alice can choose $N \approx q$ and completely remove the blinding.

Together, these bugs turn a single signature into a full key extraction.

This is the Small Paillier Attack from "Alpha-Rays: Key Extraction Attacks on Threshold ECDSA Implementations". The paper reports impact on Binance’s tss-lib and multiple forks.

Incorrect Broadcast Channel

Broadcast channels in MPC aren't just a nice-to-have, they're a security requirement. The assumption is when a party broadcasts a value, everyone receives the same value. But some implementations cut corners and implement "broadcast" as a loop that sends individual messages to each participant. That's not the same thing, and here's why it matters.

The Attack on Verifiable Secret Sharing

Recall that in Feldman VSS (the basis for Pedersen DKG), the dealer commits to a polynomial $p(x) = a_0 + a_1 x + \cdots + a_{t-1} x^{t-1}$ by publishing commitments $y_i = g^{a_i}$ for each coefficient. Each party $P_j$ receives a share $s_j = p(j)$ and verifies it using:

$$g^{s_j} \stackrel{?}{=} \prod_{i=0}^{t-1} y_i^{j^i}$$

The commitments ${y_0, y_1, \ldots, y_{t-1}}$ are supposed to be broadcast, everyone sees the same vector.

Breaking the Broadcast Assumption

Suppose the adversary wants to forge a sharing for a secret $a_0$ they don't know. Specifically, they want everyone to accept $y_0 = g^{a_0}$ as the commitment to the secret, but the adversary doesn't actually know $a_0$.

If broadcast is implemented as individual messages, the adversary can send different commitments to each party:

1. Create a truncated polynomial: Pick $p(x) = a_2 x^2 + a_3 x^3 + \cdots + a_{t-1} x^{t-1}$ (omit $a_0$ and $a_1$)
2. Send shares: Compute $s_j = p(j)$ for each party $P_j$ and send them (these are valid evaluations of the truncated polynomial)
3. Compute most commitments honestly: For $i \geq 2$, compute $y_i = g^{a_i}$ (these are the same for everyone)
4. Customize $y_1$ for each party: For each party $P_j$, compute a personalized commitment:

$$y_{1,j} = {(y_0^{-1})}^{j^{-1}}$$

5. Send different vectors: Send the vector ${y_0, y_{1,j}, y_2, \ldots, y_{t-1}}$ to party $P_j$

Why Verification Passes

Party $P_j$ checks:

$$g^{s_j} \stackrel{?}{=} \prod_{i=0}^{t-1} y_i^{j^i}$$

Expanding the right side:

$$\prod_{i=0}^{t-1} y_i^{j^i} = y_0^{j^0} \cdot y_{1,j}^{j^1} \cdot y_2^{j^2} \cdots y_{t-1}^{j^{t-1}}$$

Substituting $y_{1,j} = {(y_0^{-1})}^{j^{-1}}$:

$$= y_0 \cdot (y_0^{-j^{-1}})^j \cdot y_2^{j^2} \cdots y_{t-1}^{j^{t-1}} = y_0 \cdot y_0^{-1} \cdot y_2^{j^2} \cdots y_{t-1}^{j^{t-1}} = y_2^{j^2} \cdots y_{t-1}^{j^{t-1}}$$

The $y_0$ and $y_1$ terms cancel out! And since $s_j = p(j) = a_2 j^2 + \cdots + a_{t-1} j^{t-1}$, we have:

$$g^{s_j} = g^{a_2 j^2 + \cdots + a_{t-1} j^{t-1}} = y_2^{j^2} \cdots y_{t-1}^{j^{t-1}}$$

The check passes for every party, even though the adversary doesn't know $a_0$ or $a_1$. Each party thinks they have a valid sharing of the secret corresponding to $y_0 = g^{a_0}$, but the adversary never computed consistent shares for that secret.

This attack was described in Jake Craige’s write-up "VSS Forgery Against Bad Broadcast Channels".

Closing Thoughts

Threshold schemes remain one of our best tools for distributed trust, but the gap between "provably secure protocol" and "production-ready implementation" is real. The attacks covered here aren't exhaustive, they're a snapshot of what auditors have found. The pattern is clear: missing checks and skipped proofs. Before you ship threshold signatures to production, audit for these classes of bugs. Check parameter sizes. Validate inputs. And include all the proofs the paper specifies. The math works. Make sure your implementation does too.