Secure Multiparty Computation in Python — Core Concepts

The problem MPC solves

Multiple parties each hold private data. They want to compute a function of their combined data — a sum, a comparison, a machine learning model — but no party should learn anything beyond the final result. No trusted third party exists to collect all the data.

This isn’t just a theoretical puzzle. Any time organizations want to collaborate on data without sharing it — banks detecting cross-institution fraud, hospitals studying rare diseases across patient pools, companies benchmarking salaries — MPC provides a cryptographic solution.

Secret sharing — the foundation

The most common MPC approach is based on secret sharing. A value is split into “shares” distributed to participants. No individual share reveals anything about the original value, but combining enough shares reconstructs it.

In Shamir’s secret sharing, a secret number is encoded as a polynomial. Each participant gets a point on that polynomial. Any t points (the threshold) can reconstruct the polynomial and recover the secret, but t-1 points reveal nothing. This means the system tolerates up to t-1 colluding participants.

Additive secret sharing is simpler: split a value into random numbers that add up to the original. To share the value 42 among three parties, generate two random numbers (say 17 and -8) and compute the third as 42 - 17 - (-8) = 33. Each party gets one share: {17, -8, 33}. No single share tells you 42.

How computation works on shares

The remarkable property of secret sharing is that parties can perform calculations on their shares locally, and the results combine into shares of the correct output.

Addition is straightforward with additive shares. If party A has share a₁ of value x and share b₁ of value y, they locally compute a₁ + b₁. When all parties combine their local results, they get shares of x + y. No communication needed.

Multiplication is harder. Computing a product from additive shares requires interaction between parties — they must exchange specially crafted messages. This communication round is what makes MPC slower than local computation and why minimizing the number of multiplications is a key optimization.

Garbled circuits — the other major approach

Instead of secret sharing, garbled circuits work by representing the computation as a Boolean circuit (AND, OR, XOR gates). One party “garbles” the circuit — encrypting each gate so it can be evaluated without revealing intermediate values. The other party evaluates the garbled circuit using encrypted inputs obtained through oblivious transfer.

Oblivious transfer (OT) is a protocol where a sender has two values, and a receiver selects one without the sender learning which was chosen, and without the receiver learning the other value. It’s the cryptographic primitive that makes garbled circuits possible.

Garbled circuits excel at two-party computation with complex logic (comparisons, conditionals). Secret sharing scales better to many parties and arithmetic-heavy computations.

Security models

Semi-honest (passive) security assumes all parties follow the protocol correctly but try to learn extra information from the messages they receive. This is the most common model in practice — it’s faster and simpler.

Malicious (active) security protects against parties who deviate from the protocol — sending wrong values, aborting early, or manipulating computations. This requires additional verification steps and is 2-10x more expensive.

Most Python MPC frameworks default to semi-honest security, which is appropriate when participants are organizations with reputational incentives to behave honestly.

Communication complexity — the practical bottleneck

MPC performance is usually limited by network communication, not CPU speed. Each multiplication requires a round of communication between parties. A computation with 1,000 multiplications might need 1,000 communication rounds (though batching helps).

Over a local network with sub-millisecond latency, MPC is practical for moderate computations. Over the internet with 50ms+ latency, minimizing communication rounds becomes the dominant optimization.

Real-world deployments

The Danish sugar beet auction (2008) was the first large-scale MPC deployment — thousands of farmers submitted encrypted bids processed by three computation servers, determining market-clearing prices without revealing individual bids.

Boston Women’s Workforce Council uses MPC to compute gender pay gap statistics across companies without any company revealing individual employee salaries.

Private Set Intersection — checking if two sets share common elements without revealing non-matching elements — is used by Apple, Google, and Meta for contact discovery and ad measurement.

Common misconception

“MPC requires all parties to be online simultaneously.” While many protocols are interactive, some designs use preprocessing phases where heavy cryptographic work happens offline. The online phase — when parties actually provide inputs — can be extremely fast, sometimes completing in milliseconds.

The one thing to remember: MPC splits secrets into shares that individually reveal nothing, then lets parties compute on those shares through structured communication — trading speed for the guarantee that no party sees another’s raw data.