Multi-Party Computation in 2026

Secure multi-party computation answers a question that sounds impossible: can a group of mutually distrustful parties jointly compute a function over their private inputs while learning nothing except the output? Two hospitals comparing patient outcomes without revealing patient records; two companies measuring how many of their customers overlap without exchanging customer lists; a thousand phones training a shared model without any phone exposing its data. The theory has existed since the 1980s — Yao’s garbled circuits in 1986, the GMW and BGW protocols soon after proved that any computable function can be evaluated securely — and for almost three decades that theory was a curiosity, because doing it was thousands of times slower than just computing in the clear. The honest story of MPC in 2026 is that it has finally crossed from impossible-in-practice to deployed-in-production, but only inside a narrow envelope, and understanding the shape of that envelope is the whole point.

The envelope is defined by one stubborn fact: MPC’s cost is communication, not computation. The parties must exchange messages, often many rounds of them, and the volume and latency of that traffic — not CPU cycles — is what makes a protocol fast or unusable. That single property explains everything about where MPC succeeded and where it remains hype. It succeeded where the function being computed is small and simple (an intersection, a sum, a comparison) and the privacy requirement is legally or commercially load-bearing enough to justify the overhead. It remains impractical where the function is large and complex, like training a deep neural network from scratch, because the communication blows up faster than any hardware can absorb. MPC is not a general-purpose privacy layer you sprinkle over a system. It is a specialized, expensive instrument for a handful of high-value patterns, and in 2026 those patterns finally pay for themselves.

What MPC actually guarantees

The cleanest way to understand MPC is the ideal functionality: imagine a perfectly trusted third party who collects everyone’s private inputs, computes the function, announces the result, and forgets the inputs. MPC replaces that imaginary trusted party with a cryptographic protocol that achieves the same outcome with no trusted party at all. The guarantee has two halves: input privacy (no party learns anything about others’ inputs beyond what the output reveals) and correctness (the output is the true result, not something an attacker forged).

Two parameters define how strong the guarantee is, and conflating them is the most common error:

• Semi-honest vs malicious. A semi-honest (honest-but-curious) adversary follows the protocol but tries to learn from what it sees; a malicious adversary actively deviates, sending wrong messages to break privacy or correctness. Malicious security costs much more.
• Honest majority vs dishonest majority. Some protocols are secure only if more than half the parties are honest (information-theoretically secure, fast); others tolerate all-but-one being corrupt (cryptographically secure, slower).

One crucial boundary: MPC protects the inputs, not the output. If the agreed function is “sum of salaries” and there are two parties, each learns the other’s salary by subtraction — the protocol did its job, but the function leaked. Protecting the output itself is a different tool, differential privacy, which adds calibrated noise and composes on top of MPC. MPC is also not the same as homomorphic encryption (where one party computes on another’s encrypted data with no interaction) or a trusted execution environment (where you trust the chip vendor’s secure enclave instead of a cryptographic protocol). These are three different trust models for the same goal, and the right choice depends on who you are willing to trust and how much latency you can pay.

The protocol families, honestly

There are two foundational approaches, and modern systems mix them.

Secret sharing splits each private value into shares such that any individual share is pure noise but the shares together reconstruct the value. Shamir’s scheme (1979) uses polynomial interpolation for threshold t-of-n reconstruction; simpler additive sharing splits a value into random pieces that sum to it. Parties compute on the shares: addition is free (add your shares locally), but multiplication requires communication. The BGW and GMW protocols build general computation this way over arithmetic or boolean circuits.

Garbled circuits, Yao’s 1986 construction, is the classic two-party method: one party “garbles” a boolean circuit by encrypting its truth tables, the other evaluates it obliviously using oblivious transfer to fetch the keys for its own inputs without revealing them. Oblivious transfer is the irreducible primitive underneath nearly all MPC, and OT extension (IKNP, 2003) is what made it practical, generating millions of transfers cheaply from a few expensive base ones rooted in elliptic-curve Diffie-Hellman.

The decisive modern idea is the offline/online (preprocessing) paradigm, embodied by the SPDZ family (2012) and MASCOT (2016), which give malicious security against a dishonest majority. The expensive, input-independent work — generating correlated randomness called Beaver triples — is pushed into an offline phase done in advance; the online phase, once real inputs arrive, is fast. A Beaver triple is a secret-shared $(a, b, c)$ with $c = ab$, and it converts an online multiplication into cheap local arithmetic plus two openings:

# Online multiply of secret-shared [x],[y] using Beaver triple ([a],[b],[c=ab])
d = open([x] - [a])          # reveals nothing: masked by random a
e = open([y] - [b])          # reveals nothing: masked by random b
[xy] = [c] + d*[b] + e*[a] + d*e

The performance reality

The reason MPC is a specialized tool and not a default is visible the moment you measure it. A plaintext multiplication is a single CPU instruction, nanoseconds. A secure multiplication requires the parties to exchange messages and wait for the round trip. Over a data-center LAN that is tens of microseconds; over a WAN it is tens of milliseconds, dominated entirely by network latency. The structure of the computation maps directly onto cost:

• Circuit depth → round complexity → latency. Each layer of dependent multiplications needs a communication round, so a deep computation is latency-bound. Over a WAN, depth is the killer.
• Circuit size → bandwidth. A wide computation moves a lot of data; a billion-gate circuit moves gigabytes of protocol traffic.
• Non-linear operations are expensive. Additions and linear combinations are nearly free in secret-sharing MPC; comparisons, divisions, and the non-linearities at the heart of machine learning are costly, requiring bit-decomposition or dedicated subprotocols.

WHY GENERAL MPC ML TRAINING STAYS HARD

  plaintext matmul:   [#############] CPU only, microseconds
  MPC matmul:         [#] compute  + [######################] network rounds
                                       ^ this dominates, and it grows
                                         with model depth x iterations

This is why “MPC for private deep-learning training” is mostly marketing. Private inference on a trained model is feasible — seconds per query with frameworks like CrypTen or MP-SPDZ — but training, with its millions of iterations each adding rounds, blows the communication budget apart. Hardware does not rescue you here; a faster CPU shaves the small compute slice while the network slice, the actual bottleneck, is untouched. The practical lesson: MPC is viable when the function is shallow and small, and you should design the function to be MPC-friendly (few multiplications, minimal depth, linear where possible) rather than lift an existing computation unchanged. You can feel this directly in a framework like MP-SPDZ, where you write the function once and pick a protocol by its security model:

1
2
3
4

# Programs/Source/lt.mpc  -- compare two parties' private values
a = sint.get_input_from(0)        # party 0's secret
b = sint.get_input_from(1)        # party 1's secret
print_ln('%s', (a < b).reveal())  # reveal ONLY the comparison bit

1
2
3

./compile.py lt
./Scripts/mascot.sh lt     # malicious, dishonest-majority (slow, strong)
./Scripts/shamir.sh lt     # 3-party honest-majority (fast, weaker model)

Where it actually deployed: private set intersection

The single most successful MPC pattern in production is private set intersection (PSI): two parties, each holding a set, learn the intersection (or an aggregate over it like an intersection-sum) and nothing else. PSI is the killer app precisely because the function is tiny — set membership — so the communication stays bounded even for large sets. The workhorse construction is Diffie-Hellman based, where each party blinds its hashed elements with a secret exponent so only doubly-blinded values can be compared:

# DH-based PSI (semi-honest), parties P1, P2 with sets X, Y; secrets a, b
P1 -> P2:  { H(x)^a  for x in X }
P2 -> P1:  { H(y)^b  for y in Y }  and returns each received H(x)^a as H(x)^(ab)
P1:        raises each H(y)^b to a  -> H(y)^(ab)
match when  H(x)^(ab) == H(y)^(ab)   # equal iff x == y

The hashing that anchors this — mapping arbitrary identifiers into group elements — leans on the collision resistance covered in hash functions explained. Real deployments:

• Google’s Private Join and Compute (open-sourced 2019) does PSI plus an intersection-sum, used to measure ad conversions: an advertiser and Google learn how much revenue the overlapping users generated without either revealing its user list.
• Meta’s Private Lift Measurement runs a two-party MPC between an advertiser and Meta to compute campaign lift over the intersection of their audiences, never exchanging raw identifiers.
• Google Password Checkup uses an oblivious-pseudorandom-function PSI variant to check whether your username/password pair appears in a breach corpus without revealing your password or downloading the whole breach database.

It is worth being precise about a famous near-neighbor: Signal’s private contact discovery is often cited as MPC but actually runs inside SGX secure enclaves — a TEE trust model, not a cryptographic MPC protocol. The honest distinction matters, because Signal chose hardware trust over protocol trust for performance, exactly the trade MPC forces you to weigh. Signal’s broader double-ratchet messaging protocol is unrelated cryptography solving a different problem.

Federated learning and secure aggregation

The second real deployment is secure aggregation inside federated learning. In Google’s federated learning on Gboard, millions of phones train a shared model locally and send only model updates to a server, which averages them. But a raw update can leak the user’s data, so the server should see only the sum of updates, never an individual one. The secure-aggregation protocol (Bonawitz et al., 2017) achieves this with MPC: each pair of clients agrees on a random mask (via key agreement) that cancels out when all updates are summed, so the server recovers the aggregate while every individual contribution is hidden under noise that only disappears in the total.

ADDITIVE MASKING FOR SECURE AGGREGATION (sketch)
  client i sends:  update_i + (sum of pairwise masks with other clients)
  masks are constructed so that  Σ masks = 0  across all clients
  server computes:  Σ (update_i + masks_i) = Σ update_i   <- only the sum
  dropouts handled via threshold secret sharing of the masks

The honesty here: this is MPC applied to only the aggregation step, and it is almost always paired with differential privacy on the released model to bound what the aggregate itself reveals. Neither tool alone suffices — MPC hides the individual inputs, DP bounds the output leakage, and the combination is what makes the system defensible. Both depend critically on high-quality randomness for the masks and noise, the unglamorous foundation discussed in random number generation for engineers.

Private auctions and ad measurement

The deprecation of third-party cookies turned ad measurement into MPC’s largest new battleground, and the honest picture is a mix of MPC and TEEs that marketing tends to blur together. The genuinely MPC systems:

• Prio (Corrigan-Gibbs & Boneh, 2017) splits each client’s metric into secret shares sent to two or more non-colluding servers that compute aggregate statistics without any server seeing an individual value, with validity proofs to stop a malicious client from poisoning the aggregate. Prio is the most at-scale real MPC deployment in existence: it powered Mozilla’s Firefox telemetry, the Apple/Google Exposure Notification Privacy-Preserving Analytics during COVID, and ISRG’s Divvi Up service, and it is being standardized at the IETF as the DAP protocol with the Prio3 VDAF.
• Interoperable Private Attribution (IPA), proposed by Meta and Mozilla, computes attribution over two honest-majority helper-party MPC servers.

By contrast, Chrome Privacy Sandbox’s Attribution Reporting aggregation service runs in cloud TEEs (AWS Nitro, GCP Confidential Computing), not MPC, and the Protected Audience “Bidding and Auction” services are likewise TEE-based. Calling the whole Privacy Sandbox “MPC” is wrong; the precise statement is that the post-cookie world is being rebuilt on a blend of two-or-three-party MPC (Prio, IPA, Meta Private Lift) and trusted hardware, chosen per use case by which can meet the latency and scale budget. The pattern across all the MPC winners is identical: two or three servers under a non-collusion assumption, computing a simple aggregate, because that is the only regime fast enough to run at internet scale.

When MPC pays back the complexity

The decision of whether to reach for MPC reduces to a short checklist, and getting it wrong wastes enormous effort.

The competitors are real and often better. A TEE is far faster and simpler if you accept trusting a chip vendor’s hardware and its side-channel track record. Fully homomorphic encryption removes interaction entirely (one party computes on another’s encrypted data) but is even slower than MPC for most functions, so it wins only when round-trips are impossible. Differential privacy solves a different problem (output leakage) and complements rather than replaces MPC. And the cheapest privacy technology remains not collecting the data, which beats every cryptographic protocol when it is an option. MPC earns its keep in the seam between these: when the data genuinely must be combined, genuinely cannot move, no single party can be trusted to hold it, and the function is simple enough that the communication cost stays bounded. The privacy-vs-verifiability framing it shares with zero-knowledge proofs is worth keeping in mind: both are tools for proving something true while revealing as little as possible, and both are most powerful when the statement is small.

Verdict

Multi-party computation in 2026 is no longer a laboratory curiosity, but it is also not the universal privacy layer its boosters imply. It has crossed into real, valuable production in exactly the places the physics of the technology allows: private set intersection for ad measurement and breach checking (Google Private Join and Compute, Meta Private Lift, Password Checkup), secure aggregation for federated learning (Gboard, paired with differential privacy), and Prio-style private telemetry, which is the largest genuine MPC deployment on Earth and is now being standardized at the IETF. Every one of these wins shares the same DNA — a simple function, two or three parties or non-colluding servers, and a privacy requirement strong enough to justify the cost — because communication, not computation, is the wall, and only shallow, small functions stay under it.

The honest guidance is therefore to treat MPC as a precision instrument, not a default. Design the function to be MPC-friendly rather than lifting an existing computation; assume the network round trips, not the CPU, set your latency; pair MPC with differential privacy when the output itself could leak; and always check whether a TEE, FHE, or simply not collecting the data solves your problem more cheaply first. Where the data truly must be combined, truly cannot move, and no party can be trusted to hold it, MPC now delivers on a promise that stood unrealized for thirty years. Everywhere else, the most sophisticated cryptography is the kind you were able to avoid needing.

Sources

• Yao, “How to Generate and Exchange Secrets” (garbled circuits, 1986) — https://ieeexplore.ieee.org/document/4568207
• Damgård, Pastro, Smart, Zakarias, “Multiparty Computation from Somewhat Homomorphic Encryption” (SPDZ, 2012) — https://eprint.iacr.org/2011/535
• Keller, “MP-SPDZ: A Versatile Framework for Multi-Party Computation” — https://github.com/data61/MP-SPDZ
• Google, “Private Join and Compute” — https://github.com/google/private-join-and-compute
• Bonawitz et al., “Practical Secure Aggregation for Privacy-Preserving Machine Learning” (2017) — https://eprint.iacr.org/2017/281
• Corrigan-Gibbs & Boneh, “Prio: Private, Robust, and Scalable Computation of Aggregate Statistics” (2017) — https://crypto.stanford.edu/prio/
• IETF, “Distributed Aggregation Protocol (DAP) for Privacy Preserving Measurement” — https://datatracker.ietf.org/wg/ppm/about/
• Meta Engineering, “Private Lift Measurement and the Private Computation Framework” — https://engineering.fb.com/2023/08/24/security/privacy-aware-measurement-private-lift/
• Ishai, Kilian, Nissim, Petrank, “Extending Oblivious Transfers Efficiently” (OT extension, 2003) — https://link.springer.com/chapter/10.1007/978-3-540-45146-4_9