Pitfall Category
Insecure Subprotocols
Subprotocols assumed by the protocol design, such as broadcast channels and authenticated or confidential peer-to-peer transport, must be realized by the deployment.
Multicast Masquerading as Broadcast
What Can Go Wrong. MPC protocols such as GG18, GG20, and FROST may rely on a reliable broadcast channel for some rounds, and are often implemented by instantiating the broadcast with multicast: simply having each party send the same message to all others over P2P links. Per Goldwasser and Lindell, 2002, privacy and correctness can be achieved without full broadcast by using echo-broadcast (receivers re-send what they got and abort on mismatch), at the cost of non-unanimous abort. But echo-broadcast only achieves “broadcast with abort”: same value or $\bot$, never two different non-abort values, still strictly weaker than what these protocols assume in their published proofs. A library that cannot tell whether a given round was supposed to be broadcast or point-to-point cannot enforce reliable broadcast, and therefore cannot ensure privacy and correctness.
Security implication. Honest parties end up with different views of the same round, which can cause them to compute incompatible outputs and break correctness. In threshold signing, equivocation in a DKG commitment round leaves honest parties disagreeing on the public key; in a zero-knowledge proof round, it can let an invalid proof pass for one verifier and fail for another.
How to avoid. Implement a reliable broadcast protocol (not just echo-broadcast) for any round whose security proof requires Byzantine agreement. In settings with fewer than $n/3$ corruptions, Bracha broadcast provides the required guarantees. Enforce the per-round broadcast-vs-P2P classification at the library boundary using the protocol specification as reference, rather than delegating the decision to the caller.
Example GG18 resharing split-view attack (Kudelski, 2021)
Kudelski’s audit of ING’s threshold-ECDSA library identified a communication-layer failure in the GG18 resharing protocol. The issue was a design-level mismatch: the resharing mitigation relies on all honest parties seeing the same final confirmation, but that assumption is not realized by sending separate point-to-point messages. ING implemented the standard “forget-and-forgive” mitigation, a final ACK confirmation round before parties delete their old shares; Kudelski noted that this mitigation “might actually make things worse” if a robust broadcast channel is not available, because the final ACK can itself be equivocated. If an application realizes broadcast as $N$ separate point-to-point sends, a malicious sender can equivocate.
Kudelski’s example starts with four peers $(A, B, C, D)$ using a threshold of 3, and a resharing ceremony that adds a fifth peer $E$ while keeping the threshold at 3. At the end of the resharing protocol, malicious $E$ sends different final-round messages to different honest parties:
- $E$ sends
ACKto $A$ and $B$. - $E$ sends
not ACKto $C$ and $D$.
$A$ and $B$ believe resharing succeeded, discard their old shares, and migrate to the new committee. $C$ and $D$ believe resharing failed, keep the old shares, and do not save the new shares. The honest parties are now split between incompatible old and new committee states. Neither honest subset has enough compatible shares to sign without $E$, so the single malicious participant can lock the wallet.