Input Validation

Parties' Shares Not Validated as Non-Zero and Distinct

What can go wrong. Many MPC protocols build upon Shamir secret sharing, a $(t, n)$-threshold scheme that recovers a secret $s = f(0)$ from $t$ shares of a sharing polynomial $f(x) = s + \sum_{i=1}^{t-1} a_i x^i$ over $\mathbb{Z}_q$, with coefficients $a_i$ drawn uniformly at random. Each party $P_i$ holds the share $(i, y_i = f(i))$, and any $t$ parties can reconstruct via $s = \sum_{j} y_j \, l_j(0)$ with Lagrange basis $l_j(0) = \prod_{k, k \ne j} \frac{i_k}{i_k - i_j}$, where each $i_k$ is a party’s index (the evaluation point). Both the index $i$ and the share $x_i$ live in $\mathbb{Z}_q$, so every implementation must reduce modulo $q$ before using them. Two related failures arise when this reduction is skipped at the input boundary. First, if a party can choose its own index and the implementation rejects only the integer $0 \in \mathbb{Z}$, an attacker submitting $i = q$ (or any $k \cdot q$) passes the check while evaluatePolynomial(q) ≡ evaluatePolynomial(0) = f(0) = secret, handing it the secret directly. Second, the Lagrange basis denominator $i_k - i_j$ vanishes modulo $q$ whenever any two reconstruction indices coincide mod $q$, whether as the same raw integer (naïve duplicate) or as a malicious $i_k' = i_j + q$ (distinct as big.Int, congruent in $\mathbb{Z}_q$). The subsequent modular inverse is undefined.

Security implication. A party whose index reduces to $0 \bmod q$ is handed $f(0)$, the shared secret itself: the dealer evaluates the sharing polynomial at the attacker’s index and returns the result as normal. In a DKG, where every party deals a contribution, the attacker collects $f(0)$ from each dealer and reconstructs the full private key with no further interaction. The duplicate failure splits into two outcomes. In availability terms, reconstruction crashes with a nil-pointer dereference (Go’s ModInverse returns nil for a non-invertible input) or throws an unrecoverable error, DoS-ing the signing ceremony. In integrity terms, some implementations silently skip the offending term or substitute a default, producing an incorrect reconstruction the caller accepts as valid.

How to avoid. Validate indices at the protocol’s share-ingestion boundary: reduce each index modulo $q$, reject zero, and verify pairwise distinctness in a single pass.

Example tss-lib Shamir validation (Trail of Bits Shamir disclosure, PR #149)

Both failures appear in bnb-chain/tss-lib’s crypto/vss/feldman_vss.go and were disclosed together by Trail of Bits. They were fixed in a single PR #149.

Failure 1: zero index mod $q$. Before the fix, Create checked the party index against the integer literal 0 without reducing modulo $q$ first (source):

1// crypto/vss/feldman_vss.go, bnb-chain/tss-lib (vulnerable, pre-PR #149)
2for i := 0; i < num; i++ {
3    if indexes[i].Cmp(big.NewInt(0)) == 0 {
4        return nil, nil, fmt.Errorf("party index should not be 0")
5    }
6    // indexes[i] == q passes the check; evaluatePolynomial(q) ≡ f(0) = secret
7    share := evaluatePolynomial(ec, threshold, poly, indexes[i])
8    shares[i] = &Share{Threshold: threshold, ID: indexes[i], Share: share}
9}

A malicious party submits index $i = q$. The literal-zero check passes, but evaluatePolynomial(q) ≡ evaluatePolynomial(0) = f(0) = s, handing the attacker the shared secret as their share.

Failure 2: duplicate indices mod $q$. The same file’s ReConstruct performs Lagrange interpolation by inverting the index difference $x_j - x_k$ via ModInverse (source):

1// crypto/vss/feldman_vss.go, bnb-chain/tss-lib (Lagrange step in ReConstruct)
2sub := modN.Sub(xs[j], share.ID)
3subInv := modN.ModInverse(sub)         // nil if sub ≡ 0 mod q
4div := modN.Mul(xs[j], subInv)         // nil-pointer dereference
5times = modN.Mul(times, div)

A malicious party submits $x_j = x_k + q$ for some honest party $k$. The raw integers differ, so any non-modular != check passes; modular reduction makes $x_j \equiv x_k$, sub is zero, ModInverse returns nil, and the next operation panics, DoS-ing the signing ceremony.

Unified fix: CheckIndexes. PR #149 added a single validation helper called at the start of Create. It reduces each index modulo $q$, rejects zero, and rejects duplicates in one pass (source):

 1// crypto/vss/feldman_vss.go, bnb-chain/tss-lib (fixed, PR #149)
 2func CheckIndexes(ec elliptic.Curve, indexes []*big.Int) ([]*big.Int, error) {
 3    visited := make(map[string]struct{})
 4    for _, v := range indexes {
 5        vMod := new(big.Int).Mod(v, ec.Params().N)
 6        if vMod.Cmp(zero) == 0 {
 7            return nil, errors.New("party index should not be 0")
 8        }
 9        vModStr := vMod.String()
10        if _, ok := visited[vModStr]; ok {
11            return nil, fmt.Errorf("duplicate indexes %s", vModStr)
12        }
13        visited[vModStr] = struct{}{}
14    }
15    return indexes, nil
16}

Group Elements Not Validated in Discrete-Log Groups

What can go wrong. In MPC protocols that rely on discrete-log groups (e.g., Pedersen-VSS over safe-prime $\mathbb{Z}_p^*$, or GG18/GG20 range-proof bases in $\mathbb{Z}_{\tilde N}^*$), parties exchange elements that under exponentiation with a secret exponent may leak part or all of the secret if the element does not lie in the intended subgroup. The intended subgroup is almost always a large prime-order subgroup of $\mathbb{Z}_p^*$ (with $p = 2q + 1$ a safe prime) or of $\mathbb{Z}_{\tilde N}^*$ (an RSA-style modulus). Three checks apply to every exchanged group element:

Generator validation in safe-prime groups. A valid generator of the $q$-order subgroup of $\mathbb{Z}_p^*$ must satisfy $g \not\equiv 1 \pmod{p}$, $g \not\equiv p - 1 \pmod{p}$, and $g^{(p-1)/2} \equiv 1 \pmod{p}$. The first two exclude the trivial subgroup and the order-2 subgroup; the third confirms membership in the quadratic-residue subgroup.
Subgroup membership for received bases. For any supplied exponentiation base $x$, you must make sure $x$ lives in the intended secure subgroup by checking $x^q \equiv 1 \pmod{p}$ for a safe-prime $p$, and also check the bounds $1 < x < p - 1$ to rule out the trivial cases. Bounds-only checks catch the most degenerate values, but a generic small-order element can pass bounds and still be outside the subgroup.
Paired bases of equal subgroup order. When two bases $h_1, h_2$ are used together (as in GG18/GG20 Pedersen-style commitments $h_1^s h_2^r$), it is not enough to know each lies in the intended subgroup individually. Both must generate the same subgroup. The standard tool is a DLN proof that the sender knows $\alpha$ with $h_2 = h_1^{\alpha} \bmod \tilde N$, together with the companion proof in the reverse direction ($h_1 = h_2^{\beta} \bmod \tilde N$).

Depending on the protocol, omitting any one of these checks lets a malicious party choose an element $x$ that leaks partial or full bits of a secret exponent on every exponentiation.

Security implication. Concretely in GG18 MtA, as analyzed by Hexens, an adversary can set $h_2 = 1$ so $z = h_1^s \bmod \tilde N$ leaks $h_1^s$. When $\tilde N$ is generated without enforcing safe primes (see non-safe-prime modulus), the attacker can choose $\tilde N$ as a product of small prime factors so that $\phi(\tilde N)$ is smooth, and combining Pohlig-Hellman on each factor with CRT reconstructs the full share. Alternatively, an attacker can choose $\tilde N$ large enough that recovering $s$ reduces to computing integer logarithms, which is trivial with standard algorithms.

How to avoid. Validate every exchanged group element before any exponentiation by a secret touches it. For each element supplied by another party:

Candidate generator in safe-prime $\mathbb{Z}_p^*$: reject if $g \in \{1, p-1\}$, then check $g^{(p-1)/2} \equiv 1 \pmod{p}$ to confirm membership in the $q$-order subgroup.
Received base $x$ in $\mathbb{Z}_p^*$: for a safe-prime $p=2q + 1$, before any use of $x$, check $1 < x < p - 1$, and check $x^q \equiv 1 \pmod{p}$.
Paired bases $h_1, h_2$ in $\mathbb{Z}_{\tilde N}^*$ (the unknown-order case): reject if $h_i \in \{1, \tilde N - 1\}$ or $h_1 = h_2$; require the sender to attach a DLN proof of knowledge of $\alpha$ with $h_2 = h_1^{\alpha} \bmod \tilde N$ together with the reverse-direction proof; and require a structural proof on $\tilde N$ itself (biprimality with safe-prime factors of standard size, see non-safe-prime modulus), with a bound on $|\tilde N|$ to rule out adversarially oversized moduli. Soundness of both DLN proofs forces $\langle h_1 \rangle = \langle h_2 \rangle$; the structural proof and size bound prevent the smooth-$\phi$ and integer-log attacks respectively.

As an alternative to the bullets above for safe-prime $\mathbb{Z}_p^*$, cofactor exponentiation (RFC 2785, §3.4) raises every received element to the cofactor $j = (p-1)/q$ before use, confining all subsequent operations to the prime-order subgroup. In a safe prime $p = 2q + 1$ the cofactor is $2$, so this reduces to squaring every input ($g' = g^2$) and confines exponentiations to the prime-order subgroup without an explicit generator check.

Example tss-lib DLN bases without proofs or bounds (Trail of Bits TOB-BIN-8 fix, CVE-2020-12118, PR #89)

GG18/GG20 range proofs instantiate Pedersen commitments under auxiliary bases $h_1, h_2 \in \mathbb{Z}_{\tilde N}^*$ and assume those bases generate the same large subgroup. Two successive bugs hit the tss-lib library on this exact surface.

Original keygen broadcast ships bases with no DLN proof at all. Round 2 of ECDSA keygen stored the incoming triple $(\tilde N, h_1, h_2)$ directly, with no validation (source):

1// FILE: ecdsa/keygen/round_2.go
2// bnb-chain/tss-lib @ 6584db7f (pre-PR #89, vulnerable)
3for j, msg := range round.temp.kgRound1Messages {
4    r1msg := msg.Content().(*KGRound1Message)
5    round.save.PaillierPKs[j] = r1msg.UnmarshalPaillierPK() // used in round 4
6    round.save.NTildej[j] = r1msg.UnmarshalNTilde()
7    round.save.H1j[j], round.save.H2j[j] = r1msg.UnmarshalH1(), r1msg.UnmarshalH2()
8    // ...
9}

A malicious peer sets $h_2 = 1$ so each subsequent MtA range-proof commitment collapses to $z = h_1^s \bmod \tilde N$, revealing $h_1^s$; the attacker then reconstructs $s$ either by choosing $\tilde N$ as a product of small prime factors so $\phi(\tilde N)$ is smooth and applying Pohlig-Hellman on each factor combined with CRT, or by choosing $\tilde N$ large enough that recovery reduces to an integer logarithm problem.

PR #89 wraps the same loop with a $h_1 \ne h_2$ guard, a uniqueness check on $h_1, h_2$ across parties, and two concurrent DLN proof verifications before any party’s bases are accepted (source):

 1// FILE: ecdsa/keygen/round_2.go (lines 51-62)
 2// bnb-chain/tss-lib @ c66e035b (post-PR #89, v1.2.0+)
 3go func(j int, msg tss.ParsedMessage, r1msg *KGRound1Message, H1j, H2j, NTildej *big.Int) {
 4    if dlnProof1, err := r1msg.UnmarshalDLNProof1(); err != nil || !dlnProof1.Verify(H1j, H2j, NTildej) {
 5        dlnProof1FailCulprits[j] = msg.GetFrom()
 6    }
 7    wg.Done()
 8}(j, msg, r1msg, H1j, H2j, NTildej)
 9go func(j int, msg tss.ParsedMessage, r1msg *KGRound1Message, H1j, H2j, NTildej *big.Int) {
10    if dlnProof2, err := r1msg.UnmarshalDLNProof2(); err != nil || !dlnProof2.Verify(H2j, H1j, NTildej) {
11        dlnProof2FailCulprits[j] = msg.GetFrom()
12    }
13    wg.Done()
14}(j, msg, r1msg, H1j, H2j, NTildej)

Follow-on: Verify itself accepted degenerate $h_1, h_2$ (Trail of Bits TOB-BIN-8). Even with DLN proofs verified at keygen, the Verify routine inside crypto/dlnproof/proof.go ran the Sigma-protocol equation checks without any sanity on the inputs themselves. It accepted $h_1, h_2 \in \{0, 1, \tilde N - 1\}$ or $h_1 = h_2$, and likewise accepted arbitrary $T[i], \mathrm{Alpha}[i]$ (source):

 1// FILE: crypto/dlnproof/proof.go
 2// bnb-chain/tss-lib @ c65c3564 (pre-TOB-BIN-8, vulnerable)
 3func (p *Proof) Verify(h1, h2, N *big.Int) bool {
 4    if p == nil {
 5        return false
 6    }
 7    modN := common.ModInt(N)
 8    msg := append([]*big.Int{h1, h2, N}, p.Alpha[:]...)
 9    c := common.SHA512_256i(msg...)
10    // ... Iterations rounds of Sigma-protocol equation checks ...
11    return true
12}

The TOB-BIN-8 fix (commit c0a1d4e4) added bounds checks for $h_1, h_2$ in $(1, \tilde N)$, the $h_1 \ne h_2$ guard, and matching per-element bounds on every entry of $T[]$ and $\mathrm{Alpha}[]$ (source):

 1// FILE: crypto/dlnproof/proof.go
 2// bnb-chain/tss-lib @ c0a1d4e4 (fixed, TOB-BIN-8)
 3func (p *Proof) Verify(h1, h2, N *big.Int) bool {
 4    if p == nil {
 5        return false
 6    }
 7    if N.Sign() != 1 {
 8        return false
 9    }
10    modN := common.ModInt(N)
11    h1_ := new(big.Int).Mod(h1, N)
12    if h1_.Cmp(one) != 1 || h1_.Cmp(N) != -1 {
13        return false
14    }
15    h2_ := new(big.Int).Mod(h2, N)
16    if h2_.Cmp(one) != 1 || h2_.Cmp(N) != -1 {
17        return false
18    }
19    if h1_.Cmp(h2_) == 0 {
20        return false
21    }
22    for i := range p.T {
23        a := new(big.Int).Mod(p.T[i], N)
24        if a.Cmp(one) != 1 || a.Cmp(N) != -1 {
25            return false
26        }
27    }
28    for i := range p.Alpha {
29        a := new(big.Int).Mod(p.Alpha[i], N)
30        if a.Cmp(one) != 1 || a.Cmp(N) != -1 {
31            return false
32        }
33    }
34    // ... Sigma-protocol equation checks (Iterations rounds) unchanged ...
35    return true
36}

Curve Points Not Validated

What can go wrong. In MPC protocols that rely on elliptic-curve groups (e.g., threshold ECDSA in GG18/GG20 or BLS aggregate signatures) parties exchange curve points $(X, Y)$ that under any scalar multiplication may leak part or all of the secret, or break the soundness of an aggregation or pairing equation, if the point fails any of the validity conditions below. Three checks apply to every exchanged curve point:

Canonical encoding. Require $X, Y \in [0, p)$ at the wire boundary.
On-curve check. $(X, Y)$ must satisfy the curve equation $Y^2 \equiv X^3 + aX + b \pmod{p}$. A pair on an invalid curve $Y^2 = X^3 + aX + b'$ with smooth order $n'$ is silently processed by APIs (like Go’s elliptic.Curve.ScalarMult) that depend only on $p$ and $a$, not on the curve constant $b$. The point $(0, 0)$, which Go represents as the in-memory sentinel for the identity, is a second degenerate case and must be rejected independently.
Subgroup membership. Even an on-curve point may lie outside the intended prime-order subgroup if the curve has cofactor $h > 1$. The standard check is $q \cdot P = \mathcal{O}$ for the prime-order subgroup of order $q$, or equivalently multiplication by the cofactor with rejection of the resulting identity.

Depending on the protocol, omitting any one of these checks lets a malicious party choose a curve point $P$ that leaks bits of a secret scalar on every scalar multiplication, breaks the soundness of an aggregation or pairing-based verification, or desynchronizes the transcript and commitment state across MPC rounds.

Security implication. Missing point validation entails different attacks depending on the protocol. In ECDH protocols, an adversary supplies a point whose order has a small factor $n'$, and every scalar multiplication $k \cdot P$ by an honest secret $k$ reveals $k \bmod n'$. This primitive underlies both invalid curve attacks (Biham, Neumann, SAC 2019) and small-subgroup attacks. In threshold EdDSA over Curve25519, ZenGo’s Baby Sharks analysis showed that an injected torsion component shifts the joint key off the prime-order subgroup, so a forged signature verifies with probability about $1/8$ under some implementations while others reject it; that cross-implementation discrepancy can split honest verifiers and halt consensus. In BLS aggregation over BLS12-381, a non-subgroup public key satisfies the pairing equation for crafted signatures without knowledge of the corresponding private key, giving full signature forgery. A separate failure mode appears when the wire encoding itself is non-canonical: the same point produces different Fiat-Shamir challenges between two honest parties, splitting them across sessions and invalidating commitment openings tied to the encoded representation.

How to avoid. Validate every externally-supplied point at the wire boundary, before any scalar multiplication by a secret touches it. For each $(X, Y)$ received from another party:

Canonical range: reject if $X \not\in [0, p)$ or $Y \not\in [0, p)$.
On-curve check: reject if $(X, Y)$ does not satisfy $Y^2 \equiv X^3 + aX + b \pmod{p}$, and reject the identity $(0, 0)$ independently.
Subgroup membership (when cofactor $h > 1$): check $q \cdot P = \mathcal{O}$, where $q$ is the order of the prime-order subgroup.

For fresh curve designs, prefer a prime-order curve ($h = 1$, e.g. secp256k1 or P-256), where the subgroup check is implied by the on-curve check, or the Ristretto255/Decaf abstraction, which exposes only the prime-order quotient group and makes torsion injection structurally impossible.

Example tss-lib threshold EdDSA missing cofactor clearing (Baby Sharks, PR #115)

Standard EdDSA defends against small-subgroup attacks via bit clamping on the single-party secret scalar. The threshold EdDSA path in tss-lib applied no equivalent defense to supplied points received from peers, so as the ZenGo’s Baby Sharks analysis showed, a malicious party could inject an order-8 torsion component into the joint public key so that $1/8$ of signing ceremonies verify, while the other will reject.

In the pre-fix tss-lib, the received commitment $R_j$ was constructed straight from peer-supplied coordinates and aggregated into the joint $R$ with no subgroup-membership step (source):

1// eddsa/signing/round_3.go — bnb-chain/tss-lib (pre-fix)
2Rj, err := crypto.NewECPoint(tss.EC(), coordinates[0], coordinates[1])
3if err != nil {
4    return round.WrapError(errors.Wrapf(err, "NewECPoint(Rj)"), Pj)
5}
6// ... proof.Verify(Rj) checks knowledge of the discrete log, not subgroup ...
7extendedRj := ecPointToExtendedElement(Rj.X(), Rj.Y())
8R = addExtendedElements(R, extendedRj)

The remediation landed in PR #115. It adds an EightInvEight() helper in crypto/ecpoint.go that multiplies by 8 then by $8^{-1} \bmod N$, projecting any input into the prime-order subgroup (source):

1// crypto/ecpoint.go — bnb-chain/tss-lib (post-fix)
2var (
3    eight    = big.NewInt(8)
4    eightInv = new(big.Int).ModInverse(eight, edwards.Edwards().Params().N)
5)
6
7func (p *ECPoint) EightInvEight() *ECPoint {
8    return p.ScalarMult(eight).ScalarMult(eightInv)
9}

The helper is then applied to every received point. The patch at the signing site, mirroring the pre-fix excerpt above (source):

1// eddsa/signing/round_3.go — bnb-chain/tss-lib (post-fix)
2Rj, err := crypto.NewECPoint(tss.EC(), coordinates[0], coordinates[1])
3Rj = Rj.EightInvEight()
4if err != nil {
5    return round.WrapError(errors.Wrapf(err, "NewECPoint(Rj)"), Pj)
6}

Received Sequence Has the Wrong Length

What can go wrong. MPC protocols often handle sequences with an expected length such as Feldman VSS commitment vectors of length $t$, lists of $n-1$ peer signatures, or vectors of DLN proof iterations. Each carries a protocol-specified length that the verifier must check before using the sequence. Accepting a sequence with an unexpected shape is functionally running a different protocol instance from the one the verifier thought it was in. The same bug also appears at the lower bound: an empty proof, signature, or participant list can make a verification loop execute zero times and return success vacuously unless the expected length is checked first.

Security implication. In the context of DKG (Distributed Key Generation), a malicious party can send a Feldman VSS commitment vector of length $t + k$ while the protocol-specified length is $t$. Honest verifiers iterate over all $t + k$ elements without noticing the mismatch, surreptitiously raising the reconstruction threshold from $t$ to $t + k$ and leaving the shared key irrecoverable from the $t$ honest shares alone, unless the DKG is restarted from scratch.

How to avoid. Each party must compare the received vector length against the protocol-specified length before using the vector and abort the protocol on any length mismatch.

Example WSTS threshold-raise via oversized polynomial (Issue #87, PR #88)

WSTS (Weighted Schnorr Threshold Signatures), aka WileyProofs, is based on FROST and was vulnerable to threshold-raise attacks. Before PR #88, the per-signer DKG verification in src/v1.rs only checked the Schnorr ID, not the commitment-vector length (source):

1// src/v1.rs — Trust-Machines/wsts (vulnerable, before PR #88)
2if !comm.verify() {
3    bad_ids.push(*i);
4}
5self.group_key += comm.poly[0];

A malicious signer could append commitments to its poly to silently raise the reconstruction threshold. The Trail of Bits length-check fix in Trust-Machines/wsts landed as PR #88 (“Check length of polynomials”). PR #88 added the explicit equality check at every DKG verification site (source):

1// src/v1.rs — Trust-Machines/wsts (fixed, PR #88)
2if comm.poly.len() != threshold || !comm.verify() {
3    bad_ids.push(*i);
4} else {
5    self.group_key += comm.poly[0];
6}

List of Pitfalls