Common Multi-Party Computation Pitfalls

Welcome! This is an open, collaborative collection of common mistakes when implementing MPC protocols.

About the Project

The project is built to help developers and auditors implement MPC securely. It started at the RWMPC 2025 workshop, where practitioners from across the field agreed it needed a shared reference for the implementation mistakes that keep recurring.

On this site we have collected and categorized the most common mistakes in MPC implementations. Additionally, we track bugs across the MPC ecosystem and provide an MPC auditing skill for use with agents, both during MPC development and for known-vulnerability detection and auditing.

Categories

  • Input Validation

    In MPC protocols, parties exchange data encoded as bitstrings representing mathematical objects such as field elements, group elements, commitments and proofs. A corrupted party may supply anything, so the receiver must verify that each incoming value has the expected shape, decodes to a valid object of the expected algebraic type, and lies in the required domain. The pitfalls below arise when one of these checks is omitted, applied only to the encoding, or performed in the wrong algebraic domain.

  • Context Binding

    Zero-knowledge proofs, commitments, and signatures are important building blocks of MPC protocols, especially in threshold cryptography, which is a major category of MPC. An adversary can try to replay or transplant such artifacts from one context into another: across separate runs of the protocol (sequential or concurrent), or within a single execution (e.g. across rounds, or claiming another party’s message as its own). To prevent this, cryptographic artifacts (transcripts, commitments, signed messages) must bind uniquely to their execution context (session, parties, role, statement), so that witnesses, openings, and proofs cannot be reused across contexts.

  • Concurrency and State

    Many protocols are proven secure in particular ‘models of execution,’ and security can fail when they are run in ways that do not conform to the proof. For instance, protocols proven secure for sequential sessions can break when concurrent sessions are allowed, or preprocessing (such as Beaver triples) can be accidentally reused because a party’s state was restored from a backup.

  • 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.

  • Failure Recovery and Aborts

    When a protocol aborts, whether for benign or malicious reasons, the implementation must ensure that the failures are handled securely. What securely means is protocol-specific and may vary from: simply rerunning the protocol, removing a corrupted party, restarting other parts of the protocol, discarding some correlated randomness, or never running the protocol with the same input again.

  • Adaptive Inputs

    When a party can choose its protocol contribution after observing honest parties' messages, it can bias, cancel, or copy those contributions. Commit-before-reveal, proofs of knowledge, and binding contributions to party/session context prevent this adaptivity from changing shared protocol state.

  • Cryptographic Primitives

    The preceding classes concern how an MPC protocol wires its primitives together. The pitfalls here concern the primitives themselves: a modulus that is not a safe prime, a Paillier key with small factors, a hash used where it offers no domain separation, randomness drawn from too small a space. Each is a failure in the choice or construction of a building block, independent of the protocol wrapping it. We collect them here because the fix is local to the primitive, and the same checklist applies regardless of which protocol is being audited.

Contributors

Discuss and contribute on GitHub.