Organisations often need an answer that depends on data or keys they are not allowed, or not willing, to put in one place. Secure multi-party computation (MPC, sometimes SMPC) is a family of cryptographic protocols that lets two or more parties compute an agreed function over their combined inputs while each party learns nothing beyond the output. It sits behind threshold signing for high-value keys, MPC wallets, private set intersection between banks or statistics offices, and joint analytics that would otherwise need a trusted middleman. This explainer gives the plain-language idea first, then the detail a security architect, privacy engineer or key custodian needs to judge a proposal: security models, performance limits, what MPC does not protect and how to deploy it. For the wider set of privacy techniques, see the Privacy-Enhancing Technologies Guide.
Key takeaways
- MPC protects inputs, not outputs. Parties learn nothing beyond the agreed result, but the result itself can still reveal personal data, so output controls such as aggregation thresholds or differential privacy are still needed.
- The security model is the product. Semi-honest, covert and malicious adversaries, and honest or dishonest majority assumptions, decide what a protocol actually guarantees; ask which one before anything else.
- Key protection is the most mature use. Threshold signing and decryption let a key be used without ever existing in one place, and NIST finalised its first call for multi-party threshold schemes (NIST IR 8214C) on 20 January 2026.
- Performance is the main constraint. The UN PET Guide reports slowdowns of up to 10,000 times for general database-style work, driven mostly by network communication between parties.
- MPC does not check what you compute. If the function, the transaction or the inputs are wrong or tampered with, MPC computes the wrong thing privately; governance of inputs and approvals still matters.
What it is
Secure multi-party computation lets mutually distrusting parties compute a function on their private inputs so that each party learns the output and nothing more. The 2023 UN Guide on Privacy-Enhancing Technologies for Official Statistics describes it as addressing input privacy: two or more parties agree a function, run a protocol together and learn nothing beyond what the output reveals. The idea dates from two-party computation in 1982, was generalised to many parties later in the 1980s, and became practical for selected problems from the mid-2000s; the UN guide cites a Danish auction in January 2008 as the first large-scale practical application.
The ideal picture is a perfectly trustworthy third party who receives everyone's inputs, computes the result, announces it and forgets everything. MPC replaces that third party with a protocol, so no single party, server or administrator ever holds all the inputs in readable form.
ISO/IEC JTC 1/SC 27 standardises the field in the ISO/IEC 4922 series. Part 1 (ISO/IEC 4922-1:2023, General) sets the terminology and taxonomy; Part 2 (ISO/IEC 4922-2:2024) specifies mechanisms based on secret sharing, including addition, multiplication, shared random number generation and secure function evaluation, building on the secret sharing schemes of ISO/IEC 19592-2.
How it works
Two main techniques underpin practical protocols, and many frameworks combine them.
| Technique | How it works | Parties | Strengths | Typical uses |
|---|---|---|---|---|
| Linear secret sharing | Each input is split into random shares sent to compute parties; additions are done locally on shares, multiplications need interaction; shares are combined only for the final output | Two or many | Efficient for arithmetic and aggregation; natural fit for threshold keys | Joint statistics, threshold signing, sealed-bid auctions |
| Garbled circuits | One party (the garbler) encrypts a Boolean circuit; the other (the evaluator) obtains encrypted versions of its inputs, typically through oblivious transfer, evaluates the circuit and returns an encrypted output | Usually two | Constant number of rounds; good for comparisons and non-arithmetic logic | Two-party comparisons, private matching |
| Mixed protocols | Switch between secret sharing and garbled circuits for the parts each handles best | Two or many | Better overall efficiency | Machine learning inference, complex analytics |
| Private set intersection (PSI) | A specialised protocol that reveals only the overlap between two sets, or statistics on it | Usually two | Much faster than general MPC for matching | Record linkage, contact discovery, fraud data sharing |
A worked example in plain terms
Three hospitals want the average length of stay across all three without revealing their own figures. Each splits its number into three random shares that add up to the real value, keeps one and sends one to each of the others. Each hospital adds the shares it holds and publishes only that sum. The three published sums add up to the total, which divided by three gives the average. No hospital saw another's figure, and any single share is just a random number. Real protocols add machinery for multiplication, for checking that parties behaved, and for working over finite fields, but the principle is the same.
Security models
The UN guide sets out the adversary models that matter when comparing protocols:
| Model | Adversary behaviour | When it is acceptable |
|---|---|---|
| Semi-honest (honest but curious) | Follows the protocol but inspects everything its corrupted party sees | Parties are regulated institutions with contracts and audit, and the main risk is insider curiosity or a breach of one party's systems after the fact |
| Covert | Deviates to learn more but wants to avoid detection | Deviation carries real legal or commercial cost if caught |
| Malicious | Deviates arbitrarily and does not care about detection | Key protection, financial assets, any party that could be fully compromised |
| Honest majority vs dishonest majority | Assumes fewer than half, or allows up to all but one, of the parties to be corrupted | Dishonest majority is stronger but generally costs more; choose based on how independent the parties really are |
| Static vs mobile corruption | Adversary picks targets in advance, or moves between parties during the computation | Long-lived key shares face mobile attackers; proactive share refresh addresses this |
Why it matters
MPC removes the need to trust a single place with everything. That matters in three practical settings.
- Key protection and threshold cryptography: a signing or decryption key is generated and used in shares, so no device, administrator or cloud account ever holds the whole key. The NIST Multi-Party Threshold Cryptography project applies MPC principles to distribute trust in cryptographic operations. Its call, NIST IR 8214C, covers threshold signatures (including EdDSA, Schnorr and ECDSA), public-key encryption, ciphers such as threshold AES, key generation, threshold post-quantum schemes and building blocks such as garbled circuits, oblivious transfer and zero-knowledge proofs. See the Secret Sharing and Threshold Cryptography Guide.
- Digital asset custody: MPC wallets apply threshold signing to blockchain keys, producing an ordinary single signature while the key stays split across devices and parties. Operational controls for that setting are in the MPC Wallet and Threshold Signing Security Guide.
- Joint analytics and data collaboration: the UN guide's case studies include the Boston Women's Workforce Council measuring salary disparity with MPC, and the Italian National Institute of Statistics and the Bank of Italy using private set intersection to analyse their shared subset of individuals without directly exchanging sensitive data. Statistics Netherlands used PSI to measure the effectiveness of an eHealth service.
Choosing MPC or something else
| Need | Better fit | Why |
|---|---|---|
| Use a key without any single holder | MPC threshold signing or an HSM with quorum | MPC removes the single device; an HSM is simpler and certified but is one physical place |
| One party computes on another's encrypted data | Homomorphic encryption | No interaction between parties during computation |
| Prove a fact without revealing data | Zero-knowledge proofs | Proves a statement rather than computing a joint result |
| Hide individuals in a published result | Differential privacy | Protects outputs; often combined with MPC |
| Trust hardware instead of a protocol | Trusted execution environments | Faster, but you trust the chip vendor and its attestation |
Putting it into practice
- Define the function and the output policy: write down exactly what is computed, who receives the result and what minimum group sizes or noise apply to outputs.
- Choose the security model: match semi-honest or malicious and the corruption threshold to how independent and trusted the parties are. For keys, require malicious security.
- Place parties in genuinely separate trust domains: different organisations, cloud accounts, administrators and credentials. Three shares in one cloud tenancy under one admin team is one point of compromise.
- Review the implementation, not just the paper: ask for independent cryptographic review of the code and for how the protocol handles aborted or failed runs, which is where practical key extraction attacks have been found.
- Pilot on non-sensitive or synthetic data: measure latency, network cost and correctness against a plaintext baseline before using real data.
- Plan recovery and rollback: share backup, share refresh, party replacement and what happens if one party leaves the arrangement.
Detection and measurement
- Protocol aborts and failed runs: log and alert on them; repeated failures can indicate a party probing for leakage.
- Party and share access: each node is a non-human identity with credentials; monitor its sign-ins and administrative changes like any privileged system.
- Metrics: number of parties that would need to be compromised to recover inputs or keys; time since last share refresh; percentage of output releases checked against the output policy; independent review age of the deployed protocol version; latency against the agreed service level.
Framework mapping
| Area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Threshold key generation and use | SC-12, SC-13 | PR.DS-01 |
| Data protected during computation | SC-28 (shares at rest) | PR.DS-10 |
| Separation of parties and approvers | AC-5 | PR.AA-05 |
| Lawful basis for joint processing of personal data | PT-2 | GV.OC-03 |
Common misconceptions
- "The output is anonymous because MPC was used." MPC hides inputs only. A query that returns a statistic about a group of three people can still identify them; apply output controls.
- "MPC means the transaction is safe." Threshold approval proves enough parties agreed, not that what they agreed was correct. In the Bybit hack, multisignature signers approved what looked like a routine transfer because tampered JavaScript changed what they were shown. MPC signing is exposed to the same interface and approval risk.
- "More parties is always safer." Only if they are independent. Shares held by systems with the same administrators, cloud account or software supply chain fail together.
- "A published protocol is a secure product." Several real-world threshold ECDSA implementations have been found to leak keys through missing proofs or poor handling of failed signing sessions. Implementation review matters as much as the protocol design.
- "MPC removes data protection obligations." Joint processing of personal data still needs a lawful basis, agreements between parties and a data protection impact assessment where the risk calls for one.
- "MPC is too slow to use." It is slow for general computation, but addition-heavy aggregation, PSI and threshold signing are practical today. Fit the problem to the technique.
Related concepts
- Secret sharing: the building block that splits a value into shares, defined for standards purposes in ISO/IEC 19592-2.
- Threshold cryptography: MPC applied to a specific cryptographic operation such as signing or decryption.
- Oblivious transfer: a primitive where a receiver gets one of several values without the sender learning which, used inside garbled circuit protocols.
- Homomorphic encryption: computing on encrypted data without interaction; sometimes combined with MPC.
- Zero-knowledge proofs: used inside malicious-secure protocols to prove a party followed the rules.
- Differential privacy: the usual partner for output privacy.
Practitioner checklist
- Write down the exact function, the parties, who receives outputs and the output disclosure policy.
- Record the adversary model (semi-honest, covert or malicious) and corruption threshold, and confirm it matches the real trust between parties.
- Require malicious security and independent code review for any key protection or custody use.
- Place each party in a separate trust domain with its own administrators, credentials and cloud account.
- Protect and monitor each compute node as a privileged non-human identity.
- Log protocol aborts and failed runs, and investigate repeated failures.
- Define share backup, refresh and party replacement before go-live, and test them.
- Keep human approval and transaction display controls in place; MPC does not validate what is signed.
- Complete a data protection impact assessment for joint processing of personal data.
Standards and references
- ISO/IEC: 4922-1 Secure multiparty computation, Part 1: General
- ISO/IEC: 4922-2 Secure multiparty computation, Part 2: Mechanisms based on secret sharing
- NIST: Multi-Party Threshold Cryptography project
- United Nations: Guide on Privacy-Enhancing Technologies for Official Statistics
- ICO: What PETs are there?
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Privacy-Enhancing Technologies Guide · Secret Sharing and Threshold Cryptography Guide · MPC Wallet and Threshold Signing Security Guide · Homomorphic Encryption Guide