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}