Parag Mali - tag: secure-multiparty-computation

No Cipher Fell: How Secure Multiparty Computation Would Break

noreply@paragmali.com (Parag Mali) — Mon, 20 Jul 2026 00:00:00 GMT

**MPC does not have a security level. It has a security *relative to an adversary model*.** Every real break lives in a mis-set model knob: crossing the corruption threshold, facing a more active adversary than you assumed, demanding a fairness no dishonest-majority protocol can deliver, or composing beyond your proof. In all four cases the cryptographic primitive underneath -- the oblivious transfer, the commitment, the secret sharing -- stays perfectly intact. The one route where the primitive really is the break (a cryptanalyzed oblivious transfer, or Shor against deployed threshold signatures) is real, catastrophic, and exactly what this structural article hands off to its siblings.

1. The Protocol That Was Proven Secure, and Broke Anyway

Three servers run a secure-computation protocol whose security proof you could check line by line: no shortcut, no weak cipher, no doubtful assumption. Two of them quietly compare notes, and in a single step the private input of the third lies exposed on the table. Nothing was decrypted, no key leaked, no oblivious transfer was broken. The proof still holds. It was simply a proof about a different world than the one the protocol was deployed into.

That scene is the whole article in miniature. Secure multiparty computation has no single "security level." It has a security relative to an adversary model, and every guarantee a deployment enjoys is conditional on three knobs plus one silent assumption: the corruption threshold (how many parties the adversary may control), the adversary's behavior (does it follow the protocol, or deviate?), the promised output guarantee (does everyone receive the answer, or can one party walk off with it alone?), and the quiet premise that protocol instances run one at a time.

Cross a threshold, face a more active adversary than you modeled, demand a fairness no protocol can give, or compose beyond your proof, and MPC breaks while the cryptography underneath stands perfectly still.

A set of mutually distrusting parties jointly compute a public function of their private inputs so that each party learns the prescribed output and nothing more -- as if a trusted outside party had collected the inputs, evaluated the function, and handed back only the result. Introduced for two parties by Andrew Yao in 1982 [@yao1982] and generalized to many parties by Goldreich, Micali, and Wigderson in 1987 [@gmw1987].

This is the closing entry of How It Would Break, and its structural sibling: we interrogate the model, not the machinery. The constructive companion, "Never Decrypted: MPC and Threshold," shows how that machinery is built and why it hides what it hides [@wikipedia-mpc]. Here we take the machinery as sound and ask a narrower, sharper question: where does the guarantee actually live, and how do you kill it without touching a cipher? Four break families answer it, and each one closes on the same refrain -- no primitive fell.

If the proof is real and the primitives are sound, then the break must live somewhere the proof never promised to protect. Where, exactly, is that line?

2. The Line We Draw: What Counts as a Break

We are going to break MPC on purpose, four different ways, without touching a single cipher. To keep that promise honest, we first have to draw a line, because the phrase "MPC broke" can point at two very different failures that are not our subject.

The first is a broken primitive. Someone cryptanalyzes the oblivious transfer, forges a commitment, predicts a pseudorandom generator, or runs Shor's algorithm against the discrete-log assumption under a deployed threshold signature. When a primitive falls, security can collapse below the corruption threshold, with an honest majority intact and every party following the rules. That is a real and catastrophic failure -- but it is a story about the primitive, and this article is not about the primitive.

The second is an implementation or side-channel failure: a timing leak, an injected fault, a biased random number generator, or a soundness bug in the glue code around a threshold signature. Here the mathematics is fine and the model is fine; the physical or coded realization leaks anyway. That is the province of the real-life sibling track, not this one.

What is left when you set both aside is the adversary-model layer: the definitions, thresholds, and guarantees that sit above the primitives. This is where we work. Everything below the line -- oblivious transfer, commitments, pseudorandom generators, Shamir secret sharing, the hardness assumptions -- we seal in a black box that behaves exactly as advertised. We allow ourselves one deep fact about that box: oblivious transfer is complete, so given a working oblivious transfer you can securely compute any function at all, even with no honest majority [@kilian1988]. The box works. The question is what happens around it.

Two failure routes are named here and then deliberately set down, because a structural article that pretended they did not exist would be dishonest.

The primitive-break route: a cryptanalyzed oblivious transfer or commitment, or Shor's algorithm against the discrete-log problem beneath a threshold ECDSA or Schnorr signature. Threshold signatures now power the custody wallets of firms like Coinbase, Binance, Zengo, BitGo, and Fireblocks, and most of them rest on discrete log, so this route is not hypothetical [@nist-mpts2023]. It breaks security without any model knob being mis-set, which is exactly why it belongs to a different chapter.

The implementation and side-channel surface: timing and cache leaks, fault injection, weak randomness, and proof-soundness bugs in fielded threshold-signature libraries. The model is correct; the realization is not. That is a separate audit, owned by the real-life track.

Both are real. Neither is a break of the model, and the model is where the surprises are.

With the box sealed, here is the one-screen recap the rest leans on. In MPC, parties hold private inputs and want the output of a function on them while revealing nothing else. The gold standard for "nothing else" is an imaginary comparison: pretend a perfectly trusted outside party collected everyone's inputs, computed the function, and announced only the result. A protocol is "secure" if running it leaks no more than that ideal would [@lindell2021].

Every break in this article is a way the real execution diverges from that imagined ideal -- and the ideal itself, as we will see, is a yardstick that can be set wrong.

So the primitives are sound and the side channels are someone else's chapter. That leaves the model. But to break a model, we first have to know precisely what it was promising -- and that promise turns out to be a measuring stick that can itself be mis-calibrated.

3. The Yardstick That Can Be Wrong: The Ideal, the Real, and the Five Properties

Ask a cryptographer what "secure" means for MPC and you get a strange answer: it means as good as if a trusted outside party did it for you. The entire field is built on imagining a perfect stranger you do not actually have, and every break in this article is a way the imitation drifts from the imagination.

The definition of security used throughout MPC. Describe an *ideal world* in which a trusted party collects all inputs, computes the function, and returns only the output. A real protocol is secure if, for every adversary attacking the real execution, there exists a *simulator* attacking the ideal world that produces an indistinguishable result. In words: anything the adversary can achieve for real, it could already have achieved against the trusted party, so the protocol leaks nothing the ideal would not [@canetti2000] [@lindell2021].

The power of this definition is also its fragility. "Secure" is defined against a specified ideal and a specified adversary. Write down a different ideal -- one that tolerates aborts, or fewer corruptions, or only passive eavesdropping -- and you have proven a different theorem. The proof is not wrong; it is answering a different question than the one your deployment asks.

Unpack that ideal and it decomposes into five distinct promises. Privacy: no party learns more about the others' inputs than the output already reveals. Correctness: the output really is the function applied to the actual inputs. Input independence: each party fixes its input without knowing the others'. Fairness: either everyone learns the output or no one does. Guaranteed output delivery, or GOD: the honest parties get the correct answer no matter what the adversary tries. A given protocol satisfies some subset of these, and which subset is set by the model, not by the quality of the code.

flowchart TD G["A deployed MPC guarantee"] --> K1["Knob 1 -- Corruption threshold: how many parties may the adversary control"] G --> K2["Knob 2 -- Adversary behavior: semi-honest, covert, or malicious"] G --> K3["Knob 3 -- Output guarantee: delivery, fairness, or abort"] G --> K4["Silent premise -- Composition: do instances run one at a time"] K1 --> B1["Break Family I: cross the threshold"] K2 --> B2["Break Family II: face a more active adversary than modeled"] K3 --> B3["Break Family III: demand a fairness no protocol can give"] K4 --> B4["Break Family IV: compose beyond the proof"]

Because each property is protected by a specific assumption, we can build a ledger and fill it in as we go. This table is the article's spine rendered as accounting: read the third column as the list of assumptions we are about to violate, and the fourth as what each violation looks like on the wire.

Property	What it promises	Which model assumption protects it	What its violation looks like
Privacy	No party learns more about others' inputs than the output implies	Corruption stays below the threshold; primitives sound	Shares reconstruct; an input is read off in the clear
Correctness	The output is the true value of the function	Enough honest parties; the malicious threshold is respected	A forged output is accepted as genuine
Input independence	Each input is fixed independently of the others	The simulator can extract a fixed effective input; no concurrent mauling	A corrupt input is chosen as a function of an honest one
Fairness	Either all parties learn the output or none do	An honest majority (in general)	One party learns the output, then aborts before the others do
Guaranteed output delivery	Honest parties get the correct output no matter what	An honest majority	A single party halts the run; honest parties get nothing

Look hard at the third column, because it hides the thesis. Every one of these guarantees is a theorem only relative to the assumption beside it. Change the assumption and the theorem does not merely weaken -- it becomes false. "Secure" is not a badge the protocol carries around; it is a relationship between the protocol and a model. Two sections from now we will watch a single secret-sharing scheme be perfectly private and then fully exposed, with nothing about the scheme changing except which side of a threshold we stand on.

The maximum number of parties $t$ (out of $n$) that the adversary may control while the security proof still applies. If the proof requires more than half the parties to be honest ($t

One caveat belongs here before any break, because it is the property people most often imagine MPC has and it does not. MPC hides inputs, not outputs. Even a flawless protocol reveals the output, and the output can encode a great deal about the inputs: a two-party sum tells each party the other's number the instant they subtract their own [@lindell2021]. That leak is irreducible, present in the ideal world itself, and no construction removes it. Keep it in mind, because it will return as a wall in the theory section.

If every property is only as true as its model assumption, then the history of MPC should read as a chronicle of those assumptions being set -- and mis-set. It does. And it begins with a fork built into the field on its very first day.

4. Two Founding Worlds, and the Threshold Baked In

The wall that makes MPC break was discovered before anyone had built general MPC to break. In 1986, Richard Cleve proved a theorem about flipping a coin, and in doing so doomed a guarantee the field had not yet learned to want [@cleve1986]. To understand why that inversion matters, it helps to walk the founding decade as what it actually was: not a race to faster protocols, but the adversary model coming into focus one assumption at a time.

It opens with a question. In 1982 Andrew Yao posed the millionaires' problem -- two people learn who is richer without revealing their wealth -- and, behind it, the general problem of computing on inputs nobody will share [@yao1982]. Four years later he gave the first general engine, garbled circuits, which made two-party secure computation concrete [@yao1986]. How that engine is built is the constructive sibling's story; here it is a sealed box.

The moment the question generalized from two trusting parties to many parties who might cheat, the field split in two, and it split along a threshold.

Goldreich, Micali, and Wigderson answered the "many cheaters" case in 1987 with How to Play Any Mental Game: a protocol tolerating up to $n-1$ corruptions -- any number of cheaters -- built by taking a semi-honest protocol and forcing every party to prove in zero knowledge that it followed the rules, the construction now called the GMW compiler [@gmw1987]. The price of tolerating everyone-but-one was steep: the protocol is computational (it rests on hardness assumptions) and it is secure only with abort -- no promise that anyone actually receives the output.

A year later, Ben-Or, Goldwasser, and Wigderson took the opposite bargain. Their BGW protocol demands an honest majority and, in exchange, delivers perfect, information-theoretic security -- no computational assumptions at all -- with guaranteed output delivery, built directly on Shamir secret sharing [@bgw1988]. Chaum, Crepeau, and Damgard reached the same frontier independently the same year by a different route [@ccd1988].

Here is the framing fact the whole article rests on: from its first general day, MPC came in two feasibility worlds separated by a single threshold assumption. GMW's dishonest-majority world buys robustness against many cheaters and pays with abort. BGW's honest-majority world buys guaranteed delivery and perfect secrecy and pays with the requirement that most parties behave. Neither world is "more secure." Each is secure relative to a different adversary model, and the dividing line between them is a number: how many parties you concede to the adversary.

flowchart LR Y1982["1982 -- Yao poses secure computation"] --> C1986["1986 -- Cleve proves fairness impossible in general, the wall, proved first"] C1986 --> G1987["1987 -- GMW, dishonest majority, computational, with abort"] G1987 --> B1988["1988 -- BGW and CCD, honest majority, information-theoretic, guaranteed output"] B1988 --> UC["2000-2001 -- Canetti, stand-alone then Universal Composability"] UC --> Ladder["2002-2014 -- the abort ladder, scoped by GHKL and Cohen-Lindell"] Ladder --> Cost["2012-2018 -- the malicious-cost collapse, SPDZ, WRK, Chida"] Line up the dates and the plot twists. Cleve's fairness impossibility is 1986. GMW is 1987. BGW is 1988. The negative result that forces the dishonest-majority world to surrender fairness and guaranteed output was proved *before* either founding protocol was published [@cleve1986] [@gmw1987] [@bgw1988].

That reorders the whole story. The learn-then-abort break we will meet in Break Family III was never a design weakness the field would eventually patch with a cleverer protocol. From the day general MPC was born, giving up fairness at a dishonest majority was not debt -- it was obedience to a theorem already on the books. Everything after Cleve is the field mapping the space his wall defines.

Two details are worth pinning before we push on.Chaum, Crepeau, and Damgard's CCD protocol is BGW's information-theoretic twin: same honest-majority feasibility frontier, reached independently by a different construction, published back-to-back with BGW in the 1988 proceedings [@ccd1988]. Two teams arriving at the same boundary at the same moment is strong evidence the boundary is real, not an artifact of one design. And a name will recur so often it becomes a motif: a remarkable share of the load-bearing model-taxonomy results -- security without agreement, covert adversaries, efficient malicious 2PC, complete fairness, fairness versus delivery, the full BGW proof, cheap honest-majority malicious MPC -- carry Yehuda Lindell as a co-author [@gl2005] [@al2007] [@lp2007] [@ghkl2008] [@cl2014] [@al2017] [@chida2018]. The modern map of MPC's adversary model is disproportionately his lineage.

Two worlds, one dividing line: the corruption threshold. Everything the field learned afterward is a consequence of what happens when you stand on the wrong side of that line, or push straight past it. So let us push.

5. Break Family I: Crossing the Threshold

This is the most fundamental break, and it hides a trap that catches almost everyone. Ask "what do you lose when the adversary crosses the corruption threshold?" and there are two different correct answers. Confusing them is exactly how careful engineers ship broken systems, so we are going to keep them rigorously apart. Two answers exist because there are two ways to be on the wrong side of a threshold, and they fail in opposite properties.

Mode (a): an honest-majority protocol pushed past its threshold

BGW hides each secret as the constant term of a random polynomial of degree $t$, then hands each party one point on that polynomial [@bgw1988]. The privacy is exact and conditional. As long as the adversary sees at most $t$ shares, those points are uniformly random and pin down nothing; the moment it sees $t+1$, the polynomial is fully determined and the secret drops out by interpolation.

The safe thresholds are precise: $t<n/2$ against a passive adversary, and $t<n/3$ against a malicious one. Those exact bounds -- and the malicious bound of $t<n/3$, not the "$2t+1$" people half-remember -- were pinned down by the full modern proof of the BGW protocol [@al2017].

Why $t<n/3$ for the malicious case, and not simply "more than half honest"? The bound is set by *error-corrected reconstruction*, not by decoding a product. To stay secure against a party that hands back deliberately wrong points, the honest parties must recover each degree-$t$ sharing by verifiable secret sharing, and that error correction succeeds only when the $n-t$ honest evaluation points more than double the $t$ corrupt ones, that is $n>3t$. Naively unique-decoding the degree-$2t$ product polynomial that a multiplication produces reaches only $t<n/4$; closing the residual $n/4 \le t<n/3$ gap is exactly the job of BGW's dedicated multiplication subprotocol [@al2017].

Push one share past the passive threshold and privacy is not degraded -- it is gone. The same scheme that was information-theoretically private a moment ago now spells the secret out in the clear.

flowchart LR S["Secret s, hidden in a degree-1 sharing polynomial"] --> SH["Three points handed out, one share per party"] SH --> ONE["Adversary controls 1 share -- all p lines still fit, one per candidate secret, privacy holds"] SH --> TWO["Adversary controls 2 shares -- exactly one line fits, evaluate at zero, secret recovered, privacy gone"] TWO --> MAL["Malicious adversary also injects a bad share into reconstruction -- too few honest points to correct it, output forced wrong, correctness gone"]

The demonstration below is the entire thesis compressed into thirty lines. A degree-1 Shamir sharing splits a secret across three parties. One share is consistent with every possible secret. Any two shares reconstruct it exactly. Nothing about the scheme changes between the two cases -- only how many shares the adversary holds.

{` // Shamir sharing over the prime field GF(p). // Degree-1 polynomial f(x) = s + a*x -- any 2 shares reconstruct s = f(0). const p = 2087; const mod = (x) => ((x % p) + p) % p;

const s = 1234, a = 777; // dealer's secret and random coefficient const f = (x) => mod(s + a * x); const shares = { 1: f(1), 2: f(2), 3: f(3) }; console.log('shares handed out:', shares);

// ONE share: for any guessed secret, a matching line exists -> perfect privacy. let consistent = 0; for (let guess = 0; guess < p; guess++) { const slope = mod(shares[1] - guess); // makes f'(1) = share 1 if (mod(guess + slope) === shares[1]) consistent++; } console.log('secrets consistent with only share 1:', consistent, '(= p: all of them)');

// TWO shares: Lagrange-interpolate back to x = 0 and read the secret off. const inv = (x) => { let r = 1, b = mod(x), e = p - 2; while (e > 0) { if (e & 1) r = mod(r * b); b = mod(b * b); e >>= 1; } return r; }; function recover(pts) { let secret = 0; for (const [xi, yi] of pts) { let num = 1, den = 1; for (const [xj] of pts) if (xj !== xi) { num = mod(num * (0 - xj)); den = mod(den * (xi - xj)); } secret = mod(secret + yi * mod(num * inv(den))); } return secret; } console.log('recovered from shares {1,2}:', recover([[1, shares[1]], [2, shares[2]]])); console.log('recovered from shares {2,3}:', recover([[2, shares[2]], [3, shares[3]]])); console.log('true secret:', s, '-- the scheme kept its promise; only the assumption changed'); `}

Raise the sharing polynomial from a line to a parabola. Add a second random coefficient (`const b = 555`) and change the polynomial to `f = (x) => mod(s + a * x + b * x * x)`. The secret is now the constant term of a degree-2 curve, and it takes *three* points to pin a parabola down. Re-run `recover` with only two shares and it interpolates the wrong curve, returning garbage; pass all three and the secret reappears. The reconstruction threshold is always the polynomial degree plus one -- which is exactly the dial BGW turns to trade privacy margin against how many corruptions it tolerates.

Note: When a BGW-style protocol is run past its corruption threshold, the shares reconstruct and inputs leak. It is tempting to file this under "the crypto failed." It did not. Shamir secret sharing performed flawlessly; it was designed to let $t+1$ shares reconstruct. The false statement was the deployment's belief that the adversary would never assemble $t+1$ of them. The assumption broke, not the primitive.

In the malicious regime a second guarantee is at stake. Once $t \geq n/3$, a corrupt party can inject a wrong share during reconstruction, and with too few honest points left to error-correct, the honest parties accept an output that is simply false. So the honest-majority world draws two thresholds against two different adversaries: against a passive adversary privacy survives up to $t<n/2$, while correctness against a malicious adversary is the stricter demand and gives out first, at $t<n/3$ [@al2017].

This is the purest illustration of the article's claim, and the moment the first aha lands: "secure" was never a property the protocol had. The identical Shamir sharing is either perfectly private or fully exposed depending only on which side of a line the adversary stands. The primitive never moved. The assumption did.

Key idea: "What collapses when you cross the threshold?" has two correct answers, and they are not the same. An honest-majority protocol pushed past its threshold loses privacy and correctness -- the shares reconstruct, and past the stricter $t<n/3$ bound a malicious party's injected errors go uncorrected. A dishonest-majority protocol run correctly never loses either; it surrenders fairness and guaranteed output delivery instead. Same word, "threshold," two entirely different breaks. Say which one you mean.

Mode (b): the dishonest-majority regime, handled correctly

Now the other side of the line, and the half of the answer everyone forgets. GMW and SPDZ are built for a dishonest majority from the start. They tolerate up to $n-1$ corruptions, and when the majority does go bad they do not leak inputs and do not produce wrong outputs. Privacy and correctness both survive, with abort [@gmw1987] [@spdz2012]. Their security proof simply never promised more than "abort," so aborting is not a break of it.

What these protocols surrender instead is fairness and guaranteed output delivery -- and Cohen and Lindell proved that in the multiparty setting those are two genuinely distinct properties, not a single lump you lose together [@cl2014]. A dishonest-majority protocol can be fair for some functions yet still be haltable; it can guarantee neither in general. So "cross the threshold and you lose privacy" is at best half a truth. It describes mode (a) and badly misdescribes mode (b), where privacy and correctness are exactly what you keep.

So one "threshold break" is a privacy collapse and the other is a fairness surrender -- and the second happens only because a corrupt party can do something a merely curious one never would. Which turns the next knob: what if the adversary stops pretending to follow the rules at all?

6. Break Family II: The Adversary Who Won't Follow the Rules

A protocol proven secure against an adversary who follows the rules tells you almost nothing about an adversary who does not. That is not a small gap to paper over -- it is a category error, and running a semi-honest proof against a malicious adversary is one of the most common ways real deployments break. The second knob is the adversary's behavior, and it has three settings.

An adversary that follows the protocol exactly as specified but tries to learn everything it can from the messages it legitimately sees (its "view"). Also called passive or honest-but-curious. Security here means the view can be *simulated* from the corrupt parties' inputs and outputs alone, so it reveals nothing extra [@lindell2021]. An adversary that may deviate from the protocol in any way at all -- sending wrong messages, using inconsistent inputs, aborting, or running an entirely different program. Also called active. Security against a malicious adversary is a strictly stronger and often much costlier guarantee than security against a semi-honest one [@goldreich2004]. A middle setting, introduced by Aumann and Lindell: the adversary may cheat arbitrarily, but any cheating is detected with at least a fixed probability -- the *deterrence factor*. It models rational cheaters who will not risk being caught, trading full malicious security for a tunable chance of exposure [@al2007].

The gap between semi-honest and malicious is not incremental; it is total. Yao's original garbled-circuit protocol is "only secure in the presence of semi-honest adversaries" [@lp2007]. Put a malicious party in the garbler's seat and it can garble a different circuit than the one agreed -- say, one that simply outputs the evaluator's private input -- and the evaluator, who only ever sees the result of whatever function it was handed, has no way to notice the substitution. The semi-honest proof did not get weaker; it was never a statement about this adversary in the first place.

The covert model's twist is psychological as much as mathematical. Set the deterrence factor to, say, one-half and a cheater is caught half the time. For a bank or a consortium member whose reputation is on the line, a coin-flip chance of public exposure is plenty to enforce honesty, at a fraction of full malicious cost. Covert security reframes the question from "prevent all cheating" to "make cheating a bad bet" [@al2007].

Now the cost of closing the gap -- and here the folklore is badly out of date. "Malicious security is expensive" was true of the first construction and has been getting less true for twenty years. It is regime-dependent, not flat.

The original recipe was the GMW compiler: attach a zero-knowledge proof to every step, general and heavy [@gmw1987]. For garbled circuits, Lindell and Pinkas built the first efficient malicious 2PC from cut-and-choose -- make many circuits, open a random subset to check honesty, evaluate the rest -- warning that "a naive implementation of the cut-and-choose technique ... does not yield a secure protocol" without input-consistency enforcement [@lp2007]. SPDZ shifted the model again: authenticate every shared value with an information-theoretic MAC and check before revealing output, catching cheating at the end rather than proving it at every step [@spdz2012].

Then the penalty collapsed. In the honest-majority regime, Chida and coauthors drove malicious security to roughly twice the cost of semi-honest [@chida2018].That "twice" is a relative overhead against the same protocol's own semi-honest variant on the same circuit -- the price of adding a cheating-detection check -- not a fixed slowdown against some absolute baseline. In the dishonest-majority regime, authenticated garbling pushed the online cost to almost nothing: a maliciously secure AES evaluation in 37 ms total with a 1 ms online phase [@wrk2017], and the same lineage scaled to AES among 128 parties across five continents in under three minutes [@gs2017].

On the arithmetic side, MASCOT produced malicious preprocessing at "less than 6 times" the semi-honest cost [@mascot2016], and Overdrive's homomorphic preprocessing ran "6 times faster than MASCOT on a LAN and 20 times faster in a WAN" [@overdrive2018].

Dimension	BGW (honest majority)	GMW (dishonest majority)	SPDZ (dishonest majority)
Threshold tolerated	honest majority: $t<n/2$ passive, $t<n/3$ malicious	up to $n-1$	up to $n-1$
Security type	information-theoretic (perfect)	computational	computational, with IT MACs online
Output guarantee	GOD or fairness achievable	with abort only	with abort only
How malicious security is bought	extra honest points for error correction	zero-knowledge proof per step	IT-MAC on every value, checked before output
Malicious vs. semi-honest cost	about 2x in some settings [@chida2018]	generic ZK, heavy	preprocessing under 6x [@mascot2016]; near-free online
Collapse mode if threshold is wrong	cross $t$: privacy and correctness lost	already $n-1$: surrenders fairness and GOD by design	already $n-1$: surrenders fairness and GOD by design

Read the bottom two rows together and the point of the table jumps out. The two dishonest-majority columns differ only on engineering axes -- how malicious security is priced -- and are identical on the guarantee axis. Their output guarantee is fixed by the threshold model, not by how cleverly or cheaply they buy active security.

Chida and coauthors achieve malicious security at roughly twice the cost of semi-honest -- and it is still "secure with abort and does not achieve fairness, meaning that the adversary may receive output while the honest parties do not" [@chida2018].

Note: Notice what cheap active security did not buy. Chida's protocol is nearly free and still only secure with abort: a corrupt party can receive the output while the honest parties get nothing [@chida2018]. Fairness does not live on the cost knob. You can drive the price of honesty to almost zero and the fairness guarantee will not move a millimeter, because it is governed by a different knob entirely -- the threshold. Spending more on active security to buy fairness is spending in the wrong currency.

Which is the twist the cost story hides. You can make malicious security nearly free and still not get fairness, because fairness was never a matter of price. It was surrendered the moment you accepted a dishonest majority. And why it has to be surrendered is not an engineering shortfall at all. It is a theorem.

7. Break Family III: Learn-Then-Abort and the Fairness Impossibility

Picture the simplest possible cheat. You run the protocol honestly, you receive your answer, and then -- before anyone else receives theirs -- you hang up. You learned the output; they did not. There is no cleverer protocol that stops you, and that is not for lack of trying. There is a proof that none can exist.

The third knob is the output guarantee, and this is where it turns. In any dishonest-majority protocol, there is a moment near the end when the output becomes reconstructible from the messages sent so far plus one more. Whoever is positioned to send that final message can compute the result first and then simply decline to send it.

sequenceDiagram participant A as Alice (corrupt) participant B as Bob (honest) Note over A,B: A dishonest-majority protocol nears its final reconstruction round A->>B: honest messages so far B->>A: honest messages so far Note over A,B: Decisive round -- one more message lets each side compute the output B->>A: Bob sends his final share first Note over A: Alice reconstructs the output now A--xB: Alice aborts, withholds her final message Note over B: Bob never gets the last share, receives no output Note over A,B: Alice learned the result, Bob did not -- fairness broken, primitive intact

Why is a cheat this crude also this unstoppable? Because it is a theorem, and it was proved for the humblest function imaginable. In 1986 Richard Cleve showed that no protocol for flipping a single fair coin stays unbiased once at least half the parties can be faulty: whoever sends -- or withholds -- the last message can bias the outcome by aborting at the decisive round [@cleve1986]. Since flipping a fair coin is just a very small secure computation, the corollary is sweeping: complete fairness is impossible, in general, without an honest majority [@cleve1986].

The guarantee that either all parties learn the output or none of them do -- no party can obtain the result while denying it to an honest party. In the two-party and dishonest-majority settings, this is precisely the guarantee Cleve's theorem places out of general reach [@cleve1986] [@ghkl2008].

The demonstration below makes Cleve's argument tangible. A two-party coin flip is supposed to be unbiased. But if one party learns the result one step ahead and may abort, she biases it -- not by breaking anything, only by refusing to send when she dislikes what she sees.

{// A two-party "fair coin". The true bit is uniform. In the final round Alice // learns it one step before Bob. If she may abort, Bob falls back to a guess. function trial(aliceCheats, wants) { const coin = Math.random() < 0.5 ? 0 : 1; // the intended fair outcome if (!aliceCheats) return coin; // honest: Bob gets the true coin if (coin === wants) return coin; // she likes it -> she completes return Math.random() < 0.5 ? 0 : 1; // she aborts -> Bob's fallback guess } function rate(aliceCheats, wants, n) { let ones = 0; for (let i = 0; i < n; i++) ones += trial(aliceCheats, wants); return (ones / n).toFixed(3); } const N = 200000; console.log('honest run, P(output = 1):', rate(false, 1, N), '(fair, ~0.5)'); console.log('Alice aborts to force 1, P(output = 1):', rate(true, 1, N), '(biased up, ~0.75)'); console.log('Alice aborts to force 0, P(output = 1):', rate(true, 0, N), '(biased down, ~0.25)'); console.log('No primitive was broken -- Alice only ever refused to send a message.');}

This is the payoff of the chronological inversion from Section 4. Learn-then-abort is not an engineering weakness awaiting a fix, and no money spent on active security touches it, because it was proved impossible before general MPC was built. Spending on the behavior knob cannot buy back what the threshold knob gave away.

One guardrail keeps this insight from overshooting into a false universal. Cleve's result is "in general," not "always." In 2008, Gordon, Hazay, Katz, and Lindell overturned the folklore reading by proving that a broad class of functions can be computed with complete fairness even without an honest majority -- including Boolean AND and OR, Yao's millionaires' function, and any function without an "embedded XOR" [@ghkl2008].

So the correct statement is careful: complete fairness is impossible for some functions (those Cleve's argument reaches) at a dishonest majority, and perfectly possible for others. Anyone who says flatly "fairness is impossible without an honest majority" has overstated a theorem.

An "embedded XOR" is a $2 \times 2$ block inside a function's truth table that behaves like exclusive-or: a place where flipping either party's input flips the output. GHKL showed that functions lacking any such block -- Boolean AND and OR among them -- can be made completely fair even at a dishonest majority. The embedded XOR is, loosely, the structural feature that gives Cleve's last-message biasing attack something to grip [@ghkl2008].

If complete fairness is off the table in general, the field faced a choice: give up, or define exactly what it could still guarantee. It chose the second. And what it built was a ladder.

8. The Ladder of Weakened Guarantees

Every rung of this ladder is a concession, and the single most important thing about it is a distinction that people collapse constantly. The bottom rung -- selective abort -- is not the same thing as the impossibility that forced it into existence. One is the wound; the other is the scar. Keep them apart and the whole output-guarantee story snaps into focus.

Since complete fairness and guaranteed delivery are off the table at a dishonest majority, the field did the disciplined thing: it defined, precisely, a descending sequence of weaker guarantees and figured out exactly which are achievable where. The rule that orders them is simple: each step down drops exactly one guarantee.

flowchart TD GOD["Guaranteed output delivery -- honest parties always receive the correct output, needs an honest majority"] --> FAIR["Complete fairness -- all or none learn the output, impossible in general at dishonest majority, possible for some functions"] FAIR --> IDENT["Security with identifiable abort -- on abort, at least one cheater is publicly named"] IDENT --> UNAN["Security with unanimous abort -- all honest parties agree, all get output or all get the failure symbol, but no cheater is named"] UNAN --> SEL["Security with selective abort -- the adversary picks which honest parties get output and which get the failure symbol"] The strongest output guarantee: the honest parties are assured of receiving the correct output no matter what the adversary does -- it cannot even halt the computation. Achievable only with an honest majority, and, for $n>2$, a strictly stronger promise than fairness [@cl2014] [@bgw1988]. Security with abort, strengthened so that whenever the protocol aborts, at least one corrupt party is publicly named. It is exactly unanimous abort *plus* cheater identification -- strictly stronger than unanimous abort -- and it restores deterrence against a party that would otherwise stall the computation anonymously and indefinitely [@ioz2014]. The privacy, correctness, and input-independence guarantees all hold, but the adversary may abort -- and, in the multiparty setting, may choose *which* honest parties receive the output and which receive only a failure symbol. This is the achievable notion at a dishonest majority, formalized by Goldwasser and Lindell [@gl2005].

Walk down the rungs and watch each one shed a single promise. Guaranteed output delivery is the top, and it needs an honest majority. Complete fairness sits just below -- weaker than delivery because it permits an all-or-nothing failure, and impossible in general below an honest majority though possible for some functions.

Now fairness is gone and we are living with abort, where three rungs remain. The strongest is identifiable abort, the rung Ishai, Ostrovsky, and Zikas formalized: if the protocol aborts, it must name a cheater, so a malicious party can no longer stall the protocol anonymously and forever [@ioz2014].

Drop the naming and you get unanimous abort: the honest parties still agree -- all receive the output, or all receive the failure symbol together -- but the abort is anonymous. Drop even the agreement and you reach the floor, selective abort, where the adversary not only aborts but chooses which honest parties get the answer and which get nothing [@gl2005].

Identifiable abort therefore sits above unanimous abort, not below it: it is unanimous abort plus a named cheater, so it strictly implies the weaker rung. Reversing the two -- a common slip -- gets the concession structure exactly backwards.

Guaranteed delivery is what an honest majority buys. Selective abort is what a dishonest majority leaves you. Everything in between is the field negotiating with a theorem.

Now the clarification the whole section exists to make. It is tempting to treat "selective abort" and "the fairness impossibility" as two names for one idea. They are not. The fairness impossibility (Cleve) is the cause: a proof that you cannot have all-or-nothing delivery at a dishonest majority. Selective abort (Goldwasser-Lindell) is the consequence: the strongest guarantee the field could still define and achieve once fairness was ruled out [@cleve1986] [@gl2005]. Reason and result. Confusing them makes it sound like selective abort is a kind of impossibility, when it is actually the field's constructive answer to one.

Key idea: Selective abort is the consequence; Cleve's impossibility is the cause. The entire abort ladder exists because complete fairness is impossible in general at a dishonest majority. Selective abort is not a restatement of that impossibility -- it is the achievable floor the field engineered in response to it. And the ladder is ordered: identifiable abort ranks above unanimous abort, because it adds a named cheater. Reason and consequence, never synonyms.

Goldwasser and Lindell overturned a second piece of folklore in the same work: the belief that broadcast, or Byzantine agreement, is essential to MPC once a third or more of the parties are corrupt. They showed a cheap "echo-broadcast" suffices, decoupling agreement from privacy, correctness, and input independence -- which is exactly what lets selective abort exist as a coherent, weaker-but-achievable notion [@gl2005].

Threshold, behavior, output guarantee -- three knobs, three break families. But there is a fourth break, subtler than all of them, that a "primitives are sound" audit sails straight past: the protocol that is perfectly secure by itself and breaks the instant you run two copies of it.

9. Break Family IV: Input Substitution and the Composition Trap

The subtlest breaks do not cross any threshold and do not need a malicious garbler. They exploit the gap between what your proof covered and what your deployment actually did, and they are the ones that pass every audit -- because nothing cryptographic fails at all.

Start with a definition that is easy to get backwards. A corrupt party is always allowed to choose its own input. If a bidder lies about its valuation in a sealed-bid auction, that is not an MPC break -- the ideal trusted party would have accepted the lie too. Canetti's stand-alone definition captures this precisely: the simulator extracts an "effective input" from the corrupt party and feeds it to the ideal function, so free choice of some input is inherent and harmless [@canetti2000].

The requirement that each party fix its input independently of the others' inputs. A corrupt party may always choose *some* input of its own -- the simulator extracts an "effective input" and hands it to the ideal function -- but security breaks if the corrupt party can choose an input that *depends on* an honest party's input. Made explicit by Canetti's stand-alone definition of secure computation [@canetti2000].

The break is not free choice; it is dependence. If a corrupt party can arrange for its input to be a function of an honest party's input -- "bid exactly one dollar more than whatever she bids" -- then the ideal world, where inputs are committed independently before anything is computed, has been violated. And here is the trap: a protocol can be perfectly secure against this on its own and lose the property the moment two copies run at once.

That is because stand-alone security does not compose. Canetti's Universal Composability framework exists precisely to name and fix this gap: a protocol proven secure in isolation can fail when many instances run "in the presence of an unbounded number of arbitrary protocol instances that run concurrently in an adversarially controlled manner" [@canettiUC2001]. A man-in-the-middle who cannot break a single session can still relay and maul messages between two sessions, wiring a corrupt input in one to an honest input in the other.

sequenceDiagram participant A as Alice (session 1) participant M as Mallory (man in the middle) participant B as Bob (session 2) Note over A,B: Two instances run concurrently, each proven stand-alone secure A->>M: Session 1 message carrying a commitment to input a Note over M: Mallory does not open it -- she relays and mauls it M->>B: Session 2 message, mauled so her input becomes a function of a B->>M: Session 2 continues, its output now depends on Mallory's input Note over M: Mallory's input depends on Alice's -- input independence broken Note over A,B: No cipher failed, no threshold crossed -- the proof never covered two sessions A security definition, due to Canetti, under which a protocol proven secure remains secure under arbitrary concurrent composition with any other protocols running alongside it. UC-secure building blocks can be freely combined and reused; stand-alone-secure ones carry no such promise, and combining them can void their security [@canettiUC2001].

This is the break family with the smallest footprint and the widest blast radius. Nothing you could point at is broken. Every commitment still binds, every cipher still holds, every zero-knowledge proof still verifies, and the corruption threshold was never approached. What failed is upstream of all of that: the definition was proved for a single isolated execution and then silently reused for a deployment that runs many at once.

This is exactly why composition breaks are a primitive audit's blind spot. An auditor checking "are the primitives sound?" finds nothing wrong, because nothing is wrong with the primitives. The flawed object is the security statement -- stand-alone rather than universally composable -- and a statement that is too narrow leaves no broken artifact to discover, only a guarantee that quietly does not apply [@canettiUC2001].

So for the fourth time the refrain holds, and this time it holds in the hardest case: no cipher fell. A corrupt party made its input depend on an honest one, an honest deployment ran two sessions its proof never mentioned, and the security guarantee evaporated with every cryptographic component still working perfectly.

Four break families, four mis-set knobs, and a pattern so consistent it stops looking like coincidence and starts looking like a law. It is time to line them all up in one table -- and read the column that says the same word in every row.

10. The Master Table: Every Break Is a Model Violation

Here is the payoff. Four break families, five properties, and one yes-or-no column that compresses the whole article into a single sentence. Read the table row by row, then read the last column top to bottom.

Break family	Model knob mis-set	Property that collapses	Primitive touched?
I(a) Honest-majority protocol pushed past its threshold	Corruption threshold	Privacy and correctness	No -- Shamir sharing did exactly what it was designed to do
I(b) Dishonest-majority regime, done correctly	Threshold (accepted, not exceeded)	Fairness and guaranteed delivery	No -- privacy and correctness retained, with abort
II Semi-honest proof run against a malicious adversary	Adversary behavior	Privacy and/or correctness	No -- the proof described a different adversary
III Learn-then-abort	Output guarantee	Fairness	No -- a message was withheld; nothing was decrypted
IV Input substitution via composition	Composition (and input independence)	Input independence	No -- every cipher and commitment still held
(out of scope) Broken primitive; Shor against deployed threshold signatures	none -- the primitive itself	Any property, even below threshold	Yes -- the one route where it is the primitive

The last column is the argument. In every row where the model was mis-set, the primitive column reads no. The one row where it reads yes is the row this article deliberately set aside in Section 2 -- a cryptanalyzed oblivious transfer or commitment, or Shor's algorithm against the discrete-log assumption beneath a deployed threshold signature. That route is real and catastrophic, and it is a genuinely different kind of failure: it can break security with the model perfectly set, every party honest, and the threshold respected.

Naming it and stopping is not a dodge; it is the honesty the thesis requires. The claim was never "MPC cannot be broken." It was "MPC's structural breaks live in the model, not the machinery," and the table is that claim rendered as evidence.

Key idea: Every structural break is a model violation. Line up the four families and the "primitive touched?" column reads no in every row -- privacy from crossing a threshold, fairness from an abort, input independence from composition, none of it requiring a single cryptographic component to fail. Scoped to the adversary-model layer, with primitives assumed sound, the break is the assumption, not the primitive. The only row that reads yes is the primitive route this article hands off.

That is the third and deepest aha. One section at a time, the breaks looked like a grab-bag of unrelated attacks -- a threshold here, a garbled circuit there, a dropped message, a doubled session. Seen together they are one phenomenon in four costumes: each a knob turned to a setting the deployment could not enforce, each leaving the cryptography untouched. The diversity was an illusion of altitude; from high enough up, there is one break.

MPC's security is only as real as its adversary model. The break is the assumption, not the primitive.

If every break is a mis-set knob and not one is a broken cipher, a hopeful thought arises: surely a cleverer protocol could just fix them? For the shallow breaks, engineering helps. For the deep ones, no -- and the reason is that they are not shortfalls waiting on a better idea. They are walls, proven and load-bearing. To those walls we turn next.

11. The Walls That Make These Breaks Unavoidable

The difference between a bug and a wall is that you can fix a bug. Almost everything in this section is a wall: proven, load-bearing, and on the axes that matter, tight -- meaning the best protocol we know how to build and the best protocol that could ever exist meet at exactly the same line. Where a limit is instead merely an open engineering problem, the table says so, because conflating the two is its own kind of error.

Start with the permanent walls, each tagged with its epistemic class so you can tell a theorem from a to-do list.

Bound	Statement	Epistemic class
Cleve's fairness bound	Complete fairness, and hence guaranteed delivery, is impossible in general once at least half the parties are faulty [@cleve1986]	Theorem -- permanent wall
Honest-majority necessity	Guaranteed delivery and information-theoretic security require an honest majority; fairness and delivery are distinct for $n>2$ [@cl2014]	Theorem
Exact BGW thresholds	Perfect MPC with delivery is achievable iff $t<n/3$ malicious; the passive bound is $t<n/2$, and both are tight [@al2017]	Theorem
Oblivious-transfer completeness	Given oblivious transfer, any function is securely computable even without an honest majority [@kilian1988]	Theorem -- sufficiency
Residual output leak	Even a perfect protocol reveals the output, and the output can encode the inputs [@lindell2021]	Theorem -- irreducible
Concretely-efficient UC security	Cheap security under arbitrary concurrent composition [@canettiUC2001]	Open -- engineering
Fair-function characterization	The exact class of completely-fair functions without a majority [@ghkl2008]	Open -- theory
Efficient delivery at scale	Fault-tolerant output delivery for large party counts [@ff2021]	Open -- engineering
Post-quantum threshold gap	Standardized, efficient post-quantum threshold signatures [@nist-mptc]	Open -- out-of-scope primitive route

Every wall in the top group has the same shape: each is a counting fact about who can be corrupted or who can abort last, never a statement about a primitive's strength. Cleve's bound counts who sends the final message [@cleve1986]; the BGW thresholds count how many honest evaluation points survive to error-correct a cheater's shares [@al2017]; even the residual leak is a counting fact about information, since revealing a function of the inputs reveals something about them, and no protocol can announce the answer while hiding it [@lindell2021].

On the feasibility spine the gap is closed: BGW achieves the thresholds Cleve and the necessity results forbid anyone to beat, and the dishonest-majority ceiling of malicious-with-abort up to $n-1$ is tight against Cleve. No cleverer construction is coming to make a dishonest-majority protocol fair for a general function -- that door is shut by theorem, not by the state of the art.

The open problems are refinements, not feasibility questions, and they split by type. Making UC-secure protocols concretely cheap is engineering: composable security is proven, but its overhead over stand-alone security is steep, so practitioners who cannot pay it inherit the composition break of Section 9 [@canettiUC2001].

Characterizing exactly which functions are completely fair without a majority is theory: GHKL proved the class is broad, but its precise boundary between Cleve's "impossible" and their "possible" is unmapped [@ghkl2008]. Efficient guaranteed delivery at scale is engineering: Fantastic Four reaches delivery for four parties without a single trusted delegate, but fault-tolerant delivery for large party counts is still a frontier [@ff2021].

And then the fourth open problem, which is not really ours at all.

This is where the route this article set aside forces itself onto the deployed roadmap. Most threshold signatures securing custody wallets and exchanges today are threshold ECDSA or Schnorr, and both rest on the hardness of discrete log, which Shor's algorithm breaks on a large enough quantum computer [@nist-mpts2023]. Practical key-extraction work against fielded threshold-ECDSA wallets underlines how much production value already rides on exactly these discrete-log schemes [@makriyannis2023]. NIST's Multi-Party Threshold Cryptography project is working to standardize threshold schemes and steer them toward post-quantum-safe building blocks [@nist-mptc].

Notice what kind of break this is. No threshold is crossed. No adversary is more active than modeled. No session is doubled. The primitive assumption -- the hardness of discrete log -- is what would fall, and it would fall below the corruption threshold, with every model knob set correctly. That is precisely why it is out of scope for a structural article and precisely why it would be dishonest to omit: it is the one place the deployed reality of MPC is genuinely threatened by the primitive, not the model.

Note: Because GHKL proved some functions are fairly computable at a dishonest majority and Cleve proved others are not, "our protocol is fair" is a claim you must earn per function [@cleve1986] [@ghkl2008]. Asserting fairness without an honest majority or a proof that your specific function lies in the fair class is a direct model break -- promising a guarantee a theorem may forbid for exactly your case.

There is no single "secure." There is only secure relative to an adversary model you can enforce -- and the ideal protocol is the correct match, not a universal primitive.

The walls are fixed and, where they matter, tight. That is oddly good news. It means the practitioner's job is not to out-clever a theorem but to read the knobs correctly and deploy the protocol that matches the model they can actually enforce. So how do you keep from being the break?

12. How Not to Be the Break

Every break in this article was, at bottom, somebody deploying a protocol into a world its model did not describe. The reassuring corollary is that avoiding them is a checklist problem, not a genius problem. You do not need a new theorem. You need to state the model you are actually in and pick the protocol that matches it. Here is that checklist, each item pointing back to the section that earned it.

State your adversary model explicitly, then match the protocol to it. Write down three things before choosing any construction: the corruption threshold you face (honest or dishonest majority), the adversary's behavior (semi-honest, covert, or malicious), and the output guarantee you need (abort, fairness, or delivery). The overwhelming majority of real breaks are a mismatch between one of these and the protocol's proof, not a broken primitive. The decision guide below is that matching made mechanical.

flowchart TD Q1{"Can you enforce an honest majority?"} Q1 -->|Yes, and you need liveness| HM["Honest-majority secret sharing -- you may promise guaranteed delivery"] Q1 -->|No| DM{"LAN or WAN?"} DM -->|LAN, arithmetic| SP["SPDZ-family authenticated secret sharing -- accept security with abort"] DM -->|WAN or many parties, Boolean| AG["Constant-round authenticated garbling -- accept security with abort"] HM --> DoS{"Is one-party denial-of-service a business risk?"} SP --> DoS AG --> DoS DoS -->|Yes| IDA["Prefer identifiable abort, or delivery if you have an honest majority"] DoS -->|No| COMP{"Do instances run concurrently?"} IDA --> COMP COMP -->|Yes| UC["Use UC-secure building blocks"] COMP -->|No| DEP["Match the behavior knob, then deploy an audited framework"]

Never deploy a semi-honest protocol where inputs are adversarial. A semi-honest proof is not a weak form of malicious security; it is a statement about a different adversary and gives you nothing against one who deviates [@lp2007]. If a participant has any incentive to cheat, you need at least covert and probably malicious security.

Choose a threshold you can architecturally enforce. If you cannot guarantee an honest majority, accept security with abort and use a dishonest-majority protocol built for it -- GMW or the SPDZ family, including SPDZ2k for arithmetic over machine integers modulo $2^k$ [@spdz2012] [@spdz2k2018]. Only buy guaranteed delivery with honest-majority secret sharing if you can make the majority true through separate operators, jurisdictions, or hardware [@araki2016] [@chida2018] [@ff2021]. A threshold you merely hope holds is Break Family I waiting to happen.

Match the network and the data type. Honest-majority secret sharing and SPDZ-style protocols are strong on a LAN; for a wide-area network or many geographically spread parties, constant-round authenticated garbling pays its higher bandwidth to save round trips [@gs2017]. Arithmetic workloads favor secret sharing (and mixed frameworks like ABY3 for privacy-preserving machine learning); Boolean workloads favor garbling [@aby3-2018].

Prefer identifiable abort where one-party denial-of-service is a business risk. If a single participant halting the computation is a real operational threat, plain selective abort is a liability. Reach for identifiable abort so an aborting cheater is named, or for guaranteed delivery if you hold an honest majority [@ioz2014].

Use UC-secure building blocks when instances compose. If your MPC runs as a sub-routine, or many sessions interleave, stand-alone proofs do not cover you. Use universally composable components, or you inherit the composition break directly [@canettiUC2001].

Never claim fairness you have not proven, and never roll your own. Do not promise fairness without an honest majority or a proof that your specific function lies in the fair class [@ghkl2008]. And do not hand-build any of this: reach for audited frameworks -- MP-SPDZ across the honest/dishonest and semi-honest/malicious grid, EMP-toolkit for authenticated garbling -- and lean on the practitioner literature that maps the tradeoffs [@mpspdz2020] [@mpspdz-repo] [@empagmpc-repo] [@ekr2018].

Remember the routes this article handed off. Even a perfectly model-matched deployment can still fall to a broken primitive or a side channel. Use post-quantum-safe primitives wherever Shor is a threat to your threshold signatures [@nist-mptc], and treat the implementation surface -- timing, faults, randomness -- as its own separate audit.

Note: State your model in three numbers: threshold, behavior, output guarantee. Match the protocol to those numbers, not to a benchmark. Enforce the threshold architecturally -- never assume it. Use identifiable abort when a halt is a business risk, and UC-secure components when instances compose. Never claim fairness without an honest majority or a per-function proof. Use audited frameworks. And keep the two handed-off routes -- broken primitives and side channels -- on a separate review, because this checklist does not cover them.

The reflex to distrust is the cryptography. The discipline to master is the model. Get the knobs right and MPC is one of the most powerful tools we have; get one wrong and no proof will save you -- because the proof was never about the world you deployed into.

13. Frequently Asked Questions, and a Last Word

Because "secure" is always relative to an adversary model, and a proof only covers the model it was written for. Exceed the corruption threshold, face a more active adversary than assumed, demand a guarantee the model never promised, or run instances concurrently when the proof assumed one at a time, and the theorem simply stops applying [@canetti2000]. Nothing about the cryptography changes -- the deployment left the world the proof described. No -- and this is the single most useful distinction in the topic. An *honest-majority* protocol run *past* its threshold loses privacy and correctness: the shares reconstruct, and injected wrong shares can no longer be error-corrected [@al2017]. A *dishonest-majority* protocol run *correctly* keeps privacy and correctness (with abort) and instead surrenders fairness and guaranteed delivery [@spdz2012] [@cl2014]. Same word "threshold," two different failures. Impossible *in general* without an honest majority: Cleve proved even a fair coin flip can be biased once at least half the parties are faulty [@cleve1986]. But not *always* -- Gordon, Hazay, Katz, and Lindell showed a broad class of functions, including Boolean AND and OR and the millionaires' problem, can be computed with complete fairness even at a dishonest majority [@ghkl2008]. Fairness is a per-function question below an honest majority. No. The fairness impossibility is the *cause* -- Cleve's theorem that complete fairness is unachievable in general at a dishonest majority [@cleve1986]. Selective abort is the *consequence* -- the strongest guarantee the field could still define and achieve in its place, where the adversary may abort and even choose which honest parties receive output [@gl2005]. One is the reason; the other is the response. And on the ladder itself, identifiable abort ranks *above* unanimous abort -- it is unanimous abort plus a named cheater, not below it [@ioz2014]. No, and the folklore is decades out of date. In the honest-majority regime it can cost about twice the semi-honest price [@chida2018]; in the dishonest-majority regime, preprocessing pushes the *online* cost to near-free, with maliciously secure AES in about 37 milliseconds and a 1 millisecond online phase [@wrk2017]. The penalty is regime- and era-dependent -- and, importantly, buying it still does not buy fairness [@chida2018]. Choosing *some* input, no -- that is inherent, and the simulator simply extracts an effective input for the ideal function [@canetti2000]. The break is input *dependence*: a corrupt party choosing an input as a function of an honest party's input, which the ideal world forbids. It typically appears through concurrent composition, where stand-alone security offers no protection [@canettiUC2001]. Those are real risks, but they are a different chapter. This article is about *structural* breaks in the adversary model. Implementation flaws, timing and fault side channels, and a broken primitive -- a cryptanalyzed oblivious transfer, or Shor against a deployed threshold signature -- are the two routes it explicitly hands off [@nist-mpts2023]. They can break a perfectly model-matched deployment, which is exactly why they deserve their own audit rather than a footnote here.

So the story closes where it began, with a proof that held and a system that failed anyway. Across four break families the primitive column read no every time: privacy fell to a crossed threshold, correctness to a corrupted reconstruction, fairness to a withheld message, input independence to a doubled session -- and not one oblivious transfer, commitment, or secret-sharing scheme was ever broken.

MPC has no absolute security level. It has a security relative to an adversary model, and the deep discipline of deploying it is not distrust of the cryptography but precision about the model you can actually enforce.

For how the machinery this article sealed in a black box is actually built -- the secret sharing, the oblivious transfer, the commitments that never fell -- see the constructive companion, Never Decrypted: MPC and Threshold [@wikipedia-mpc]. And Part 12 of this series, A Valid Proof of a False Thing, tells the same story one layer down in zero-knowledge proofs, where a valid proof of a false statement is likewise never a broken cipher but a mis-set model.

The pattern, by now, should feel inevitable: when cryptography breaks in the ways this series studies, look first not at the math, but at the assumption the math was answering.

The Trusted Party Nobody Has to Be: Secure Multiparty Computation and Threshold Cryptography, Where No One Holds the Secret

noreply@paragmali.com (Parag Mali) — Mon, 20 Jul 2026 00:00:00 GMT

Secure multiparty computation (MPC) lets mutually distrusting parties jointly compute an agreed function over their private inputs while learning nothing but the output, as if an incorruptible trusted party ran the computation, except no one ever gets to be that party. One humble primitive, oblivious transfer, is provably enough to build it, and three classic constructions -- Yao's garbled circuits, GMW, and BGW -- trade rounds against bandwidth against trust assumptions in opposite ways. Threshold cryptography is the deployed special case: fix the function to "sign" or "decrypt," generate the key as shares, and it is used but never reassembled, which is why an MPC custody wallet can truthfully say no single box holds the key. The honest catch: MPC hides inputs, not outputs; complete fairness is provably impossible for general-purpose computation when most parties are dishonest; and most shipped threshold signatures still rest on the discrete logarithm, the gap NIST's post-quantum threshold call now targets.

1. Compute on It, but Nobody Gets to See It

Two hospitals each hold half the patients in a rare-disease study, and one shared statistic could save lives. Neither is allowed to see the other's records. The obvious fix, "hand both datasets to a trusted broker," just moves every secret into a single database that can be hacked, subpoenaed, or bribed. Down the street, a custodian must sign a billion-dollar transfer, and any one server that holds the signing key is one breach away from catastrophe. In each case the answer everyone reaches for -- a trusted party in the middle -- is precisely the party nobody can afford to trust.

This article is about the forty-five-year project to build that party out of pure protocol, so that no one ever has to be it. That is the one idea the whole piece defends: mutually distrusting parties can jointly compute a function over private inputs while learning only the output, and the special case where the function is "sign" or "decrypt" splits a key so that no single party -- or box -- ever holds it [@lindell21-cacm].

A set of parties, each holding a private input, run a protocol that computes an agreed function and reveals only its output. No party learns anything about the others' inputs beyond what the output itself implies. The security goal is stated by comparison to an ideal world in which a trusted party collects the inputs, computes the function, and hands back only the result [@lindell21-cacm, @ekr-monograph].

One refrain recurs in every section: each technique is a different way to simulate an incorruptible trusted party -- one who takes all private inputs, computes the agreed function, and returns only the result, without anyone ever getting to play that party.

Three sharp lines keep the primitives from blurring together, because this is Part 3 of a series and each part hides data a different way.

These four privacy technologies answer different questions under different trust models. **[Fully homomorphic encryption](/blog/never-decrypted-how-fully-homomorphic-encryption-computes-on/)** (Part 1) lets one server compute on *your* single ciphertext, so trust rests on a hardness assumption, not on other parties. **[Zero-knowledge proofs](/blog/never-decrypted-proving-you-ran-the-computation-without-reve/)** (Part 2) let one prover convince one verifier that a computation ran correctly, revealing nothing else. **MPC** splits the trust itself across several parties, so privacy holds as long as too few of them collude. A **trusted execution environment** trusts hardware rather than mathematics. This post owns the third door, and it also draws a line against the sibling secret-sharing post: [that post splits a key so it can be reconstructed once, later](/blog/nobody-broke-shamir-a-field-guide-to-secret-sharing-and-thre/); this post computes on shared data and uses keys without ever assembling them.

The invariant that ties them is blunt: no party ever sees a value in the clear that it is not entitled to see. Everything below is the machinery that enforces it, and the honesty about what the machinery still cannot do.

Key idea: The trusted third party is not the cure. It is the disease. Its database is the breach surface, and the same box that can compute the answer can be hacked, subpoenaed, or bribed. MPC's move is not to make the trusted party safer -- it is to remove it entirely, and simulate its behavior with a protocol that gives the same output and leaks nothing more.

Every technique in this article is a different way to simulate the trusted party nobody has to be.

Before we can build a party out of protocol, though, we need to say precisely what "secure" even means. Otherwise we are just trading a trusted party for a wish.

2. The Yardstick: The Ideal World You Simulate

In 1982, at Berkeley, Andrew Yao asked a question that sounds like a party riddle. Two millionaires want to know who is richer, but neither will reveal how much money he has. Can they learn the single bit "who is larger" and nothing else? Yao's paper turned that riddle into the founding question of a field: can a computation be as good as handing your inputs to a trusted party you never actually have to trust [@yao82]?

The riddle exposes a harder question underneath. Suppose someone hands you a protocol and swears it "leaks nothing." How would you even check that claim? "Leaks nothing" is not a property you can eyeball in a transcript of messages.

The answer is the definition the entire discipline rests on, and it is worth stating carefully because every later construction is judged against it.

A protocol is secure if whatever an adversary can learn by participating in the *real* protocol, it could also have computed in an *ideal* world where a trusted party takes all inputs, evaluates the function, and returns only the output. Formally, a *simulator* given only the ideal-world output must be able to reproduce the adversary's entire real-world view. If it can, the real protocol reveals nothing the ideal output did not already imply [@lindell21-cacm, @ekr-monograph].

That is the whole trick of defining privacy: "secure" means "as good as a trusted party you never have to trust." The strongest version of this idea, universal composability, demands that the guarantee survive even when the protocol runs concurrently alongside arbitrary other protocols [@canetti01-uc].

flowchart TB subgraph REAL["Real world -- a protocol"] ax[A holds input x] --> msgs[Rounds of protocol messages] by[B holds input y] --> msgs msgs --> rout[Output f of x and y] end subgraph IDEAL["Ideal world -- a trusted party"] ax2[A holds input x] --> tp[Incorruptible trusted party] by2[B holds input y] --> tp tp --> iout[Output f of x and y] end adv[Adversary view in the real run] -. must be reproducible by .-> sim[Simulator given only the ideal output]

The definition also exposes the knobs every real protocol has to set. These choices, not raw speed, are what separate one construction from another.

A *semi-honest* (honest-but-curious) adversary follows the protocol exactly but tries to infer private inputs from the messages it sees. A *malicious* (active) adversary may deviate arbitrarily: lie about its input, send malformed messages, or abort. Security against a malicious adversary is strictly harder and usually more expensive, and a protocol proven only semi-honest is worthless against an attacker willing to cheat [@lindell21-cacm]. In the *honest-majority* setting the adversary corrupts fewer than half the parties; in the *dishonest-majority* setting it may corrupt all but one. The distinction is not cosmetic: information-theoretic security and guaranteed output are possible with an honest majority, while a dishonest majority forces reliance on cryptographic assumptions and, as we will see, gives up the guarantee that everyone receives the answer [@ekr-monograph].

Two more knobs matter. Fairness asks whether either everyone gets the output or no one does. Guaranteed output delivery asks whether honest parties are assured of the answer even if others quit. Both turn out to be luxuries you cannot always buy.

There is one caveat so important that misunderstanding it undoes everything. The guarantee is "nothing beyond the output," and the output itself can be revealing.

Note: MPC promises that parties learn nothing beyond the agreed output. It does not promise the output is safe. If two parties compute their sum, each learns the other's number by subtraction. If they compute "who is richer," the poorer party learns an upper bound on the richer one. Choosing a function whose output leaks too much is a design error no protocol can fix, and it is the single most common misconception about what MPC buys you [@lindell21-cacm].

Keep one table open and fill it in as each construction arrives. Here it is seeded with the two anchors we already have: the ideal we are simulating, and Yao's special-purpose answer.Yao framed his 1982 result as the "millionaires' problem" precisely because a wealth comparison is the smallest interesting function whose output is a single bit yet whose inputs must stay hidden [@yao82].

What is hidden	Who computes	Adversary model	Parties	Rounds	Trust assumption
All inputs	One trusted party	None, by fiat	n plus a broker	1	Total trust in a single box (the thing we remove)
Both wealth values	The two parties themselves	Semi-honest	2	A few	A hardness assumption; no trusted party

The definition says a trusted party can be simulated. It does not say how, or out of what. The smallest answer turns out to be almost insultingly humble.

3. The Engine: Oblivious Transfer, and Why One Primitive Is Enough

In 1981, Michael Rabin described a primitive that sounds like a bug report. A sender transmits a message that the receiver gets with probability one-half, and the sender never learns whether it arrived [@rabin81-ot]. Why would anyone want a channel that loses your mail at random and hides the tracking number from you?

Because that lossy, blindfolded channel turns out to be the entire trust engine of secure computation. The version everyone actually uses was pinned down by Even, Goldreich, and Lempel in 1985 and is cleaner to state.

The sender holds two messages, `m0` and `m1`. The receiver holds a choice bit `b`. After the protocol the receiver learns `m_b` and nothing about `m_(1-b)`, while the sender learns nothing about `b`. Two secrets are kept at once: the receiver's choice is hidden from the sender, and the unchosen message is hidden from the receiver [@egl85]. sequenceDiagram participant R as Receiver picks bit b participant S as Sender holds m0 and m1 R->>S: blinded choice that hides b Note over R,S: the sender cannot tell which message R wants S->>R: encrypted pair only b can unlock Note over R: R opens exactly the chosen message Note over R: the other message stays unreadable Note over S: the sender never learns b

Here is a toy version you can run. The parameters are tiny and the key-derivation is a stand-in, so this is illustration, not production cryptography, but the information flow is faithful: the receiver publishes two keys whose product is a fixed value, knows the secret behind only one of them, and can therefore open only the message it chose.

{` // Bellare-Micali-style OT with BigInt. Tiny params, toy key-derivation. const p = 2147483647n; // Mersenne prime 2^31 - 1 const g = 7n; const C = 1234567n; // fixed element; nobody knows its discrete log

function modpow(base, exp, mod) { let r = 1n; base %= mod; while (exp > 0n) { if (exp & 1n) r = (r * base) % mod; base = (base * base) % mod; exp >>= 1n; } return r; } const inv = (a, mod) => modpow(a, mod - 2n, mod); // Fermat inverse const kdf = (x) => Number(x % 100000n); // toy key-derivation

// Receiver: publish two keys with product C, but know the secret for pk[b] only. function receiver(b, k) { const pk = [0n, 0n]; pk[b] = modpow(g, k, p); pk[1 - b] = (C * inv(pk[b], p)) % p; return pk; } // Sender: verify pk0*pk1 = C, then mask each message with a key from pk[i]^r. function sender(pk, m0, m1, r) { if ((pk[0] * pk[1]) % p !== C) throw new Error("receiver cheated"); const gr = modpow(g, r, p); return { gr, c: [m0 + kdf(modpow(pk[0], r, p)), m1 + kdf(modpow(pk[1], r, p))] }; }

for (const b of [0, 1]) { const k = 987654n, r = 424242n; const pk = receiver(b, k); const { gr, c } = sender(pk, 111, 222, r); const keyB = kdf(modpow(gr, k, p)); // = pk[b]^r, the only key R can form console.log("receiver chose b=" + b + " -> recovered " + (c[b] - keyB) + " (wanted " + (b === 0 ? 111 : 222) + ")"); } console.log("to open the other message R would need the discrete log of C, which it lacks"); `}

Now the earthquake. In 1988 Joe Kilian proved that oblivious transfer is complete: given a secure OT and nothing else, you can securely compute any function at all [@kilian88]. No additional cryptographic assumption is required. One blindfolded either-or choice is a universal building block, exactly the way a single NAND gate can express any Boolean circuit.

Key idea: Kilian's completeness theorem is the reason the rest of this article is engineering rather than invention. You do not need a bespoke protocol for each function you care about. Secure oblivious transfer alone is enough to compute everything, so the whole problem reduces to building good OT and wiring it into circuits.

Oblivious transfer is to secure computation what NAND is to Boolean logic: one humble gadget, and everything else follows.

"Complete" is a theorem, not a performance promise, and the naive way to use it hits a wall immediately. Each OT, done from scratch, costs a public-key operation, the same expensive modular exponentiation you just watched. A circuit with a million AND gates would need on the order of a million public-key operations, which is far too slow to ship.

The fix is one of the quiet triumphs of the field. In 2003, Ishai, Kilian, Nissim, and Petrank showed how to extend oblivious transfer: starting from about 128 real base OTs, you can produce millions more using only fast symmetric-key operations, no further public-key crypto [@iknp03].The IKNP trick inverts the roles of sender and receiver over a matrix of random bits, so that a mere 128 genuine OTs "bootstrap" an effectively unlimited supply. Later work tightened the constants for practical use [@otext13]. The modern endpoint of that line is silent OT, where two parties expand short correlated seeds into vast amounts of OT-like randomness with almost no communication, resting on the learning-parity-with-noise assumption [@silentot19].

That engine is shared by the dishonest-majority constructions we turn to next, the garbled-circuit and secret-sharing lines. So one primitive suffices. But "suffices" is a theorem, not a blueprint. How do you actually turn blind one-of-two choices into a working joint computation? The field found three different answers at once, and, awkwardly for anyone who likes tidy stories, all three are still in use.

4. The Evolution: Three Ways to Instantiate the Trusted Party

Between 1986 and 1988 the field produced three distinct general-purpose constructions with opposite trade-offs, and they coexist to this day. Read that sentence carefully, because the tempting story is wrong. This is a fork, not a ladder. Garbled circuits did not "evolve into" secret sharing, and none of the three is simply better than the others. In particular, and this is the single most-abused point in popular explanations, a garbled circuit is not a secret-sharing scheme. It is built from symmetric encryption and oblivious transfer.

If all three constructions can securely compute anything, why do all three still exist? Because each buys a different resource cheaply, and no application needs all resources at once.

timeline title Simulating the trusted party, 1981 to 2026 1981 : Rabin introduces oblivious transfer 1982 : Yao poses the millionaires problem 1985 : Even-Goldreich-Lempel fix 1-out-of-2 OT 1986 : Yao garbled circuits, first general 2PC 1987 : GMW, anything is computable securely 1988 : BGW and CCD go information-theoretic, Kilian proves OT complete 1991 : Beaver triples split work into offline and online 2003 : IKNP OT extension makes OT cheap at scale 2012 : SPDZ, cheap malicious security at a dishonest majority 2024 : FROST standardized as RFC 9591 2026 : NIST IR 8214C calls for multi-party threshold schemes

Yao's garbled circuits: constant round, two parties

Yao's 1986 construction was the first protocol that could securely compute any function of two parties' inputs [@yao86]. Its shape is unlike anything in the secret-sharing world.

A Boolean circuit encrypted so it can be evaluated blind. The *garbler* assigns each wire two random labels, one standing for 0 and one for 1, then replaces every gate's truth table with encryptions keyed by the input-wire labels. The *evaluator*, holding exactly one label per input wire, can decrypt exactly one row of each gate and learns only an output label, never the underlying bit. The evaluator gets its own input labels by oblivious transfer, so the garbler never learns the evaluator's input. Garbling is symmetric encryption plus OT; it is not secret sharing [@yao86, @mit-ygc]. flowchart TB g0[Garbler assigns two random labels per wire] --> g1[Garbler encrypts each gate truth table under input labels] g1 --> g2[Send garbled circuit plus garbler input labels] g2 --> ot[Evaluator obtains its input labels by oblivious transfer] ot --> ev[Evaluator decrypts one row per gate and learns only output labels] ev --> dec[Output labels decode to the result]

The defining virtue is round complexity. The garbler encrypts the whole circuit and sends it in one shot, the evaluator runs it locally, and the number of communication rounds does not grow with the circuit's depth. On a high-latency link between two continents, where each round-trip costs real milliseconds, that constant-round behavior is decisive.

The walls are just as concrete. The construction is inherently two-party. The entire garbled circuit must be transmitted, so communication grows with circuit size. And in its original form each AND gate cost four ciphertexts, one per row of the truth table, which point-and-permute lets the evaluator index directly [@mit-ygc].The FOCS 1986 abstract of record is titled "How to Generate and Exchange Secrets," but the garbling construction itself is credited to Yao's oral presentation and later expositions, not spelled out in that short abstract. It is a mild historical irony that the most famous protocol in the field has no canonical originating paper for its own mechanism [@yao86].

Those costs launched a decade of optimization. Free-XOR (2008) made every XOR gate cost zero ciphertexts by fixing a global offset between a wire's two labels [@freexor08]. Half-gates (2015) drove each AND gate down to two ciphertexts and proved that two is optimal for a broad class of linear garbling schemes, completing an arc from four to three to two [@halfgates15].

BMR (1990) lifted garbling to n parties while keeping the constant-round property, by having all parties jointly garble one circuit [@bmr90]. And authenticated garbling reached malicious two-party security at roughly 37 milliseconds total, about 1 millisecond online and about 6.7 milliseconds amortized per AES block, which is fast enough to be unremarkable [@wrk17-authgarbling].

GMW: many parties, sharing plus OT, rounds that grow with depth

A year after Yao, Goldreich, Micali, and Wigderson gave a different answer that scales to n parties [@gmw87]. Every wire value is split into XOR (additive) shares, one per party, that reveal nothing until combined. XOR gates are then completely local: each party XORs its own shares, no messages required. The cost lives entirely in AND gates.

Writing a shared bit x as the XOR of the parties' shares and likewise for y, the product x AND y expands into a sum of cross-terms, one for each pair of parties, and each cross-term is settled by a single oblivious transfer between that pair. Correctness for AND, privacy for everything, and the only cryptography in sight is OT.

{` // Split each bit into three XOR shares that reveal nothing on their own. function share(bit) { const s1 = Math.round(Math.random()); const s2 = Math.round(Math.random()); const s3 = bit ^ s1 ^ s2; // the three shares XOR back to the secret return [s1, s2, s3]; } const reveal = (sh) => sh[0] ^ sh[1] ^ sh[2];

const x = 1, y = 0; const X = share(x), Y = share(y);

// Each party XORs its OWN two shares locally. No messages are exchanged. const Z = [X[0] ^ Y[0], X[1] ^ Y[1], X[2] ^ Y[2]];

console.log("shares of x =", X, " reveal ->", reveal(X)); console.log("shares of y =", Y, " reveal ->", reveal(Y)); console.log("local XOR of shares reveals ->", reveal(Z), " and x XOR y =", (x ^ y)); console.log("one share of x alone is", X[0], "-- a uniform bit, so it tells you nothing"); `}

The trade-off is the mirror image of Yao's. Because each layer of AND gates needs a round of interaction, the number of rounds grows with the circuit's depth. On a fast local network that is fine; across a high-latency wide-area link, depth-many round-trips are the dominant cost. So the field already had two general constructions that were fast in exactly opposite conditions.

GMW also supplies the cleanest bridge to the previous post in this series. The base protocol is only semi-honest secure, but the GMW compiler upgrades it to malicious security by having every party prove, in zero knowledge, that each message was computed correctly from committed inputs and honest randomness. That is zero-knowledge proofs doing exactly the job Part 2 described, bolted onto MPC. The honest footnote is that generic per-gate zero-knowledge is concretely expensive, and in practice it was largely superseded by the SPDZ-style techniques we reach in the next section [@lindell21-cacm].

BGW and CCD: an honest majority buys unconditional security

The third answer, from Ben-Or, Goldwasser, and Wigderson in 1988, and independently from Chaum, Crepeau, and Damgard the same year, dispenses with cryptographic assumptions entirely [@bgw88, @ccd88]. Instead of XOR shares it uses Shamir secret sharing over a finite field, where each secret is a point on a random polynomial [@shamir79]. Addition of shared values is local, as before. Multiplication is the hard step: multiplying two degree-t sharings yields a product of degree 2t, which must be re-shared and its degree reduced back to t through a round of interaction. That degree-reduction step is the engine of BGW.

The security bounds are exact, and getting them right matters because they are widely misquoted.The completeness-theorem cluster is a genuine piece of conference drama: in the STOC 1988 proceedings, BGW (pages 1 to 10), CCD (pages 11 to 19), and Kilian's OT-completeness result (pages 20 to 31) sit on consecutive pages. Three foundational answers to "what is computable securely" arrived at one meeting [@bgw88, @ccd88, @kilian88]. BGW gives perfect privacy against a passive adversary that corrupts fewer than half the parties, t < n/2, and perfect privacy and correctness against a malicious (Byzantine) adversary corrupting t < n/3. Those thresholds are tight, and the malicious bound is t < n/3, not the "2t+1" that appears in careless summaries.

If you accept a negligible error probability and assume a broadcast channel, Rabin and Ben-Or later pushed the malicious threshold to t < n/2 [@rabin-benor89]. The price of dropping all assumptions is the honest majority itself, plus heavy per-multiplication interaction.

The move that ties the modern secret-sharing world together came from Donald Beaver in 1991, and it is the reason "MPC is slow" is the wrong mental model.

A precomputed, secret-shared triple `([a], [b], [c])` where `a` and `b` are uniformly random and `c = a * b`, produced in an input-independent *offline* phase. In the *online* phase, multiplying two shared values `[x]` and `[y]` costs only opening `d = x - a` and `e = y - b`, then recombining locally. Because `a` and `b` are uniform, `d` and `e` reveal nothing about `x` and `y`, and the expensive work of making the triple happened before the inputs existed [@beaver91].

Beaver triples split every secret-sharing protocol into a heavy, function-independent offline phase and a cheap, information-theoretic online phase. That shape is the direct ancestor of nearly all modern secret-sharing MPC, including the breakthrough in the next section.

With three constructions and one unifying trick in hand, the security ledger has filled out. Notice that it is not a ranking. Each row wins a different column.

What is hidden	Who computes	Adversary model	Parties	Rounds	Trust assumption
All inputs	One trusted party	None, by fiat	n plus a broker	1	Total trust in a single box (removed)
Both wealth values	The two parties	Semi-honest	2	A few	A hardness assumption
Both inputs	Garbler and evaluator	Semi-honest to malicious	2 (BMR: n)	Constant	Symmetric crypto plus OT; dishonest majority
All inputs	n parties on XOR shares	Semi-honest to malicious via ZK	n	Grows with depth	OT; dishonest majority given OT
All inputs	n parties on Shamir shares	Perfect, up to `t < n/3` malicious	n	Grows with depth	None; honest majority

The same coexistence, read as engineering trade-offs rather than a timeline, is the comparison every practitioner eventually internalizes.

Dimension	Yao garbled circuits	GMW	BGW / CCD	SPDZ family
Rounds	Constant	Grows with depth	Grows with depth	Cheap online, heavy offline
Communication	Whole circuit; 2 ciphertexts per AND (half-gates)	1 OT per AND	Interaction per multiplication	Cheap online; heavy offline triples
Parties	2 (BMR: n)	n	n	n
Majority	Dishonest	Dishonest, given OT	Honest (`t < n/2` passive, `t < n/3` malicious)	Dishonest (`n-1`)
Assumptions	Symmetric crypto plus OT	OT	None (information-theoretic)	Offline: SHE or OT; online: IT given the MAC key
Best suited for	2PC on high-latency links	n-party Boolean on a LAN	Honest majority, no assumptions, fairness	Malicious n-party arithmetic

flowchart TB goal[Simulate the trusted party for any function] --> y[Yao garbled circuits] goal --> g[GMW] goal --> b[BGW and CCD] y --> yt[Constant round, two parties, symmetric plus OT, dishonest majority] g --> gt[Depth rounds, n parties, OT, dishonest majority given OT] b --> bt[Depth rounds, n parties, no assumptions, honest majority]

Note: Yao's garbled circuits, GMW, and BGW are three different building blocks, not three rungs of one evolution. Garbled circuits use symmetric encryption and OT; GMW and BGW use secret sharing. They win in different network conditions and trust models, which is exactly why all three are still deployed almost forty years later. Any explanation that presents them as a single lineage has hidden the most useful thing about them.

Beaver triples make multiplication cheap, but the version described so far only holds against a passive adversary. For twenty years the practitioner's dilemma was that malicious security, a dishonest majority, and practicality were pick-two. Then one idea got all three at once.

5. The Breakthrough: Cheap Malicious Security at a Dishonest Majority

Put yourself in the shoes of a practitioner around 2010. You can have information-theoretic security, but only with an honest majority you may not have. Or you can tolerate a dishonest majority, but only against a passive adversary, or by paying for a per-gate zero-knowledge compiler so expensive it is closer to a threat than a tool. The question that hung over the field was blunt: how do you catch a cheater who controls every party but you, without drowning in public-key cryptography?

SPDZ, from Damgard, Pastro, Smart, and Zakarias at CRYPTO 2012, answered it with a single idea [@spdz12].The name is the authors' initials and is pronounced "speedz," which doubles as an accurate performance claim about its online phase. The idea is to authenticate every shared value so that tampering is caught the instant a value is opened.

Key idea: Attach an information-theoretic message authentication code to every secret share. A single global MAC key, itself secret-shared and never revealed, guards all values at once. Any party that alters a share must forge a MAC it cannot compute, so one cheap check at the end catches a dishonest majority of active cheaters, and all the heavy cryptography hides in an offline phase that runs before any input exists.

Concretely, a global MAC key $\alpha$ is secret-shared and never opened. Every value x is stored twice over: the parties hold shares of x and shares of $\alpha \cdot x$, and linear operations preserve this relationship automatically. Multiplications consume authenticated Beaver triples generated offline, originally through somewhat-homomorphic encryption, later through oblivious transfer in the MASCOT variant and through faster homomorphic encryption in Overdrive [@spdz12, @spdz2-12].

At the end, a single MAC check verifies that nobody altered a value. To cheat undetected, an adversary would have to produce a valid MAC $\alpha \cdot (x + e)$ for an error e without knowing $\alpha$, which succeeds only with probability about $1/|\mathbb{F}|$ over the field.With a 128-bit field that cheating chance is around $2^{-128}$, far below any threshold anyone worries about. Make the field large and that probability is negligible.

A two-phase protocol structure. The *offline* (preprocessing) phase runs before any inputs are known and produces input-independent correlated randomness, such as authenticated Beaver triples, using the expensive cryptography. The *online* phase consumes that material to evaluate the actual function with cheap, mostly information-theoretic operations. Throughput is usually bounded by how fast the offline phase can manufacture triples [@spdz12, @beaver91]. flowchart TB subgraph OFFLINE["Offline phase -- input independent"] o1[Manufacture authenticated Beaver triples] --> o2[Heavy crypto: SHE or OT] end subgraph ONLINE["Online phase -- cheap and information-theoretic"] n1[Secret-share inputs with their MAC shares] --> n2[Evaluate circuit, consume triples] n2 --> n3[One MAC check catches any tampering] n3 --> n4[Open only the output] end OFFLINE --> ONLINE

The online phase is exactly the Beaver-triple trick, now doing real work. Here it is, running:

{` const P = 65537; // work in a prime field const mod = (a) => ((a % P) + P) % P; const rnd = () => Math.floor(Math.random() * P); const shareVal = (v) => { const s0 = rnd(); return [s0, mod(v - s0)]; }; // 2-party additive const open = (sh) => mod(sh[0] + sh[1]);

// OFFLINE: one random triple ([a],[b],[c]) with c = a*b, made before inputs exist const a = rnd(), b = rnd(), c = mod(a * b); const A = shareVal(a), B = shareVal(b), C = shareVal(c);

// Secret inputs, secret-shared between two parties const x = 12345, y = 54321; const X = shareVal(x), Y = shareVal(y);

// ONLINE: open only d = x - a and e = y - b. Because a,b are uniform, these leak nothing. const d = open([mod(X[0] - A[0]), mod(X[1] - A[1])]); const e = open([mod(Y[0] - B[0]), mod(Y[1] - B[1])]);

// Each party forms its share of xy locally: [xy] = [c] + d[b] + e*[a] + de const Z0 = mod(C[0] + d * B[0] + e * A[0] + d * e); // one party adds the public de const Z1 = mod(C[1] + d * B[1] + e * A[1]);

console.log("opened only d = x - a and e = y - b:", d, e, "(uniform, reveal nothing)"); console.log("reconstructed xy =", open([Z0, Z1])); console.log("direct xy =", mod(x * y)); `}

The result is a protocol that securely computes any arithmetic circuit against up to n-1 malicious parties, with a cheap online phase and a single integrity check. It did not get superseded; it got refined. The SPDZ family is the current shape of general-purpose MPC, and the reference framework MP-SPDZ implements more than thirty protocol variants across the whole trade-off space [@mpspdz20, @mpspdz-github]. Modern offline phases increasingly draw their correlated randomness from silent OT, shrinking the preprocessing communication toward nothing [@silentot19].

Note: When a modern system says it runs "maliciously secure MPC at a dishonest majority," it is almost always in the SPDZ family: authenticated secret shares, an offline triple factory, and a cheap online phase. Treat it as the baseline against which other choices are justified [@mpspdz20].

The general-purpose ledger is now complete, with SPDZ as the entry that finally combined the three properties the field had spent two decades unable to get together.

What is hidden	Who computes	Adversary model	Parties	Rounds	Trust assumption
All inputs	One trusted party	None, by fiat	n plus a broker	1	Total trust in a single box (removed)
Both wealth values	The two parties	Semi-honest	2	A few	A hardness assumption
Both inputs	Garbler and evaluator	Semi-honest to malicious	2 (BMR: n)	Constant	Symmetric crypto plus OT; dishonest majority
All inputs	n parties on XOR shares	Semi-honest to malicious via ZK	n	Grows with depth	OT; dishonest majority given OT
All inputs	n parties on Shamir shares	Perfect, up to `t < n/3` malicious	n	Grows with depth	None; honest majority
All inputs	n parties on authenticated shares	Malicious, up to `n-1` corruptions	n	Cheap online, heavy offline	Offline crypto; online IT given the MAC key

SPDZ can securely compute any arithmetic circuit against almost everyone cheating. But most of the world does not need "any function." It needs exactly one function, over and over: sign this, or decrypt this. Fix the function, and something remarkable falls out.

6. The Deployed Special Case: Threshold Cryptography, Where No One Holds the Key

Here is the reframing that pays off the whole article. Take the general machinery and fix the function f to just one operation: sign, or decrypt. Now the simulated trusted party has exactly one job, and its only output is a signature or a plaintext. If the key is never handed to anyone, where does it actually live?

The answer is that it never becomes a thing at all. Through distributed key generation, the private key is born as shares and is never reconstructed, not even at setup.

Threshold cryptography splits a private key into shares held by `n` parties so that any authorized threshold of them can perform the secret-key operation, while fewer than the threshold learn nothing and the key is never assembled. *Distributed key generation* is the setup protocol that produces the public key together with a secret sharing of the matching private key, so the private key exists only as shares from the very first moment. The construction mechanics -- Lagrange interpolation at signing time, verifiable sharing, proactive refresh -- are developed in the companion [secret-sharing post](/blog/nobody-broke-shamir-a-field-guide-to-secret-sharing-and-thre/) [@rfc9591].

This is the sharp boundary with the sibling post, and it is worth drawing in bright lines, because the two ideas look similar and behave oppositely.

A Shamir backup and an MPC signing key are both "a secret split into shares," but they differ at the decisive moment. A **backup** is a reconstruct-once design: you split a key to store it safely, and one day you gather the shares and rebuild the whole key to use it. A **threshold signing key** is a never-reconstruct design: the key is used, again and again, without ever being assembled anywhere. There is no moment when the full private key sits in memory. That is why an MPC custody wallet can truthfully claim no single box has ever held the key, a claim a backup scheme cannot make [@rfc9591, @cbmpc].

Key idea: Threshold cryptography is not a separate subject from MPC. It is MPC with the function permanently fixed to "sign" or "decrypt." Everything in the first five sections applies, but because the function is fixed, the protocols can be specialized until they run in milliseconds, and the output is an ordinary signature any standard verifier accepts.

A signature scheme split so that any authorized subset of `n` signers can jointly produce a signature that verifies under a single ordinary public key, while no smaller subset can sign and the private key is never reconstructed. To the outside world the result is indistinguishable from an ordinary signature; the sharing is invisible to the verifier [@rfc9591, @shoup00]. sequenceDiagram participant P1 as Party 1 holds a share participant P2 as Combiner holds a share participant P3 as Party 3 holds a share participant V as Any standard verifier Note over P1,P3: distributed key generation, the private key is never assembled Note over P1,P3: each party computes a partial signature from its own share P1->>P2: partial signature one P3->>P2: partial signature three Note over P2: combine partials into one ordinary signature P2->>V: a single standard signature Note over V: verifies under the ordinary public key, blind to the sharing

The easy case is Schnorr. Because Schnorr signatures are linear, partial signatures simply add up, which makes the scheme friendly to thresholdize. FROST is the deployed standard here, and in 2024 it became RFC 9591, the first threshold-signature RFC, defining five ciphersuites and a two-round signing protocol [@rfc9591, @frost20].FROST stands for Flexible Round-Optimized Schnorr Threshold. The "round-optimized" part is the selling point: signing takes two rounds, and a preprocessing variant pushes the online phase to effectively one [@frost20].

The hard case is ECDSA, and it is instructive precisely because it fights back. ECDSA signing requires multiplying two shared secrets and inverting a shared nonce, neither of which is linear, so thresholdizing it took real invention. Lindell made two-party threshold ECDSA practical in 2017 at roughly 37 milliseconds on the P-256 curve [@lindell17-ecdsa].

From there the deployed line split into two branches that still compete. One uses Paillier encryption for its multiplicative-to-additive conversion: GG18, its follow-up GG20, and the proactive, identifiable-abort CGGMP protocol that ships as Fireblocks' MPC-CMP [@gg18, @cggmp20]. The other avoids Paillier entirely and does the multiplication with oblivious transfer: the DKLs line, two-party in 2018 and multiparty in 2019, tested to hundreds of parties [@dkls18, @dkls19].

Dimension	Paillier-MtA (GG18 / GG20 / CGGMP)	OT-based (DKLs18 / DKLs19)
Multiplication primitive	Paillier MtA plus range proofs	Oblivious transfer, no Paillier
Rounds to sign	Multi-round; CGGMP has a non-interactive online phase	`log(t)+6`, two-party optimized
Communication	Lower bandwidth	Higher bandwidth from OT
Per-party compute	Heavier, Paillier operations	Lighter, symmetric and OT
Two-party signing time	Tens of milliseconds	Single-digit milliseconds on a LAN
Scale tested	Small to moderate `n`	Up to 256 parties, embedded devices
Extra features	Identifiable abort, proactive refresh, UC	Fewest assumptions
Known integration risk	TSSHOCK / BitForge in the range proofs	Newer analysis surface, no Paillier
Deployed in	Fireblocks MPC-CMP and many custody stacks	Wallet SDKs favoring Paillier-free designs

Signing is not the only fixed function. Set f to decrypt and you get threshold decryption, where a ciphertext is jointly decrypted by share-holders without ever assembling the key, the pattern behind distributed key-management services and virtual hardware security modules. Victor Shoup showed as early as 2000 that a threshold of parties could produce standard RSA signatures without assembling the key [@shoup00], and Coinbase's open-source cb-mpc library is built for exactly this deployment [@cbmpc].

The key is never a value in any box. It is a capability the group can exercise but no single member can hold.

There is one honest asterisk on all of this, and it points at the future. Almost every deployed threshold signature rests on the discrete logarithm, which a large quantum computer would break with Shor's algorithm. The framework itself can be post-quantum -- BGW needs no computational assumption at all -- but the keys people actually ship are not. That gap is precisely what NIST is now moving on.

In January 2026, NIST finalized Interagency Report 8214C under its Multi-Party Threshold Cryptography project. It is a *First Call for Schemes*: a request for public submissions, organized into Class N for selected NIST-specified primitives and Class S for special ones including fully homomorphic encryption, zero-knowledge proofs, and auxiliary gadgets. Threshold ML-DSA, the post-quantum lattice signature, sits in Class N as an invited target. The precise verb matters: the call *places threshold ML-DSA in scope*. NIST has not standardized a threshold ML-DSA scheme, and saying it has is simply wrong [@nistir8214c, @nist-mptc, @nist-news-8214c].

With that, the special case takes its place as the final row of the ledger. The function is fixed, the output is a signature, and the "trust assumption" column now reads: the key is never assembled.

What is hidden	Who computes	Adversary model	Parties	Rounds	Trust assumption
The private key itself	`n` share-holders	Malicious, scheme-dependent	n	2 (FROST) to a few	Key never assembled; discrete-log hardness today

"No one holds the key" is not marketing. It is a property you can verify from the protocol. So where is it actually running today, and does the theory survive contact with production?

7. Where It Ships: Three Deployment Homes

The theory is settled; the products are here. The discipline that keeps this section honest is to attribute every deployment by a chain: the scheme (a named protocol from a paper), the library that implements it, and the product that ships the library. Skip a link and you get the marketing gloss instead of the engineering.

The first home is MPC custody. When an exchange or bank holds cryptocurrency, the signing key is the whole ballgame, and a single server holding it is a single point of catastrophic failure. So custody vendors run threshold ECDSA. Fireblocks ships MPC-CMP, whose scheme is the CGGMP protocol from CCS 2020 and whose core is open-sourced as mpc-lib [@fireblocks-mpccmp, @cggmp20]."MPC-CMP" is named for the CGGMP protocol of CCS 2020 -- Canetti, Gennaro, Goldfeder, Makriyannis, and Peled -- not "Centralized Multi-Party" as a widely copied web gloss claims. Mind the initials: those five surnames spell CGGMP, while the bare acronym "CMP" is the three-author Canetti-Makriyannis-Peled line, so "CMP" should never be expanded to the five CGGMP names. The whole point of the design is that nothing is centralized [@cggmp20].

Coinbase open-sourced cb-mpc, which packages threshold ECDSA, Schnorr, and EdDSA with DKG, OT, and zero-knowledge proofs [@cbmpc, @coinbase-mpc-blog]. BitGo runs threshold ECDSA and EdDSA on the same never-reconstruct principle [@bitgo-tss]. In every case the signing key is generated as shares and used without assembly.

That home also gives the series its sharpest cautionary tale, and it is the reason this post keeps insisting that an implementation bug is not a broken idea.

In 2023, the BitForge and TSSHOCK disclosures (CVE-2023-33241) showed that wallets built on the GG18 and GG20 threshold-ECDSA protocols could leak a full private key. An attacker who injected a malformed Paillier key and cheated in the accompanying range proof could extract the signing key in as few as 16 signatures, and the flaw touched more than ten libraries [@cve-2023-33241, @verichains-tsshock]. Read the failure precisely: it was an *implementation* bug in the Paillier-modulus validation bolted around the shares, not a break of the threshold-ECDSA idea. The core protocol was sound; the surrounding proof machinery was misimplemented [@fireblocks-tsshock-report, @safeheron-bitforge]. It is also a direct argument for the Paillier-free OT branch, which has less bolted-on machinery to get wrong.

The second home looks nothing like the first. Private analytics gathers statistics from millions of devices without collecting anyone's individual data. Prio, from Corrigan-Gibbs and Boneh in 2017, is the template: each client splits its report into secret shares sent to a small number of non-colluding aggregators, which sum the shares and reconstruct only the aggregate, never any individual value [@prio17].The privacy rests on the aggregators not colluding: any single aggregator sees only uniform-looking shares, so the guarantee holds as long as at least one of them is honest. Correctness is enforced by secret-shared validity proofs, so a malicious client cannot poison the total without detection.

This is aggregation-style MPC, quite distinct from garbled-circuit two-party computation, and it is being standardized at the IETF as the Distributed Aggregation Protocol (DAP) -- still a working-group draft -- while already running in production in ISRG's Divvi Up, alongside Apple and Google's Exposure Notifications analytics and Mozilla telemetry [@ietf-dap, @divviup]. These systems also add differential-privacy noise to the aggregate, a reminder that MPC protects the inputs while the output still needs its own defense [@enpa-whitepaper]. Newer aggregation systems lean on function secret sharing, which splits a function rather than a value into two short keys, with the distributed point function as its point-query special case; Poplar uses exactly that to find frequent strings across many clients without a trusted aggregator, where Prio used plain additive shares [@dpf-gi14, @fss-bgi15, @poplar21].

The most widely shipped special-purpose two-party computation is quieter than any of these. Private set intersection lets two parties learn only the elements their sets share, or an aggregate over those elements, and nothing else. Its clearest deployed form is privacy-preserving ad-conversion measurement, where Google's Private Join and Compute reveals only the size and value of an intersection and nothing about the individual records on either side [@psi-ion20]. Mobile contact discovery is the example people reach for, but it sharpens this article's thesis rather than illustrating it: the flagship privacy messenger, Signal, runs its production contact discovery inside an Intel SGX secure enclave with remote attestation [@signal-pcd] -- a trusted execution environment that trusts hardware, not a cryptographic two-party computation that trusts mathematics. Cryptographic private contact discovery has been demonstrated at scale as a research integration [@psi-kales19], yet messengers have not shipped it in place of enclaves. The construction mechanics are their own subject; the point here is that the flagship deployed 2PC is not a general circuit but this one tightly specialized function -- and where it genuinely ships, it ships as cryptography, not as hardware trust.

The third home is distributed key management. A conventional key-management service or hardware security module concentrates trust in one box; the threshold version spreads it. Coinbase's cb-mpc doubles as a distributed KMS [@cbmpc], the virtual-HSM vendor Unbound was folded into Coinbase [@coinbase-unbound], and systems such as Zama's threshold key-management service keep decryption keys secret-shared, running sign and decrypt operations without ever reconstructing the full key [@zama-tkms]. The keys live only as shares, on purpose, from creation to retirement.

Workload	Scheme	Library	Product or deployment
Custody signing	CGGMP threshold ECDSA	Fireblocks mpc-lib	Fireblocks MPC-CMP
Custody signing	Threshold ECDSA, Schnorr, EdDSA	Coinbase cb-mpc	Coinbase custody and wallet services
Custody signing	Threshold ECDSA and EdDSA	Proprietary	BitGo
Private analytics	Prio secret-shared reports with validity proofs	libprio and DAP	Divvi Up, Exposure Notifications, Mozilla telemetry
Private set intersection	PSI (ad-conversion, aggregates)	Audited PSI protocols	Google Private Join and Compute
Private heavy hitters	Function secret sharing / DPFs	DPF-based (Poplar)	Heavy-hitter analytics without a trusted aggregator
Distributed KMS or virtual HSM	Threshold ECDSA and decryption	cb-mpc, Unbound, Zama TKMS	Custody KMS and virtual HSM offerings

Note: When you evaluate an "MPC" product, ask which named scheme its library implements and which paper defines that scheme. "We use MPC" is not an answer. "We run the CGGMP protocol with proactive refresh, or the DKLs OT-based protocol" is. The attribution tells you the trust model, the failure modes, and whether the code path that broke in TSSHOCK is even present [@cggmp20, @dkls19].

Every one of these systems made the same trade, and every trade has a price. It is time to be honest about the costs, and about the walls that no amount of engineering can move.

8. The Honest Costs and the Theoretical Limits

If MPC can compute anything privately, why is not everything already private? The lazy answer is "MPC is slow," and it is the wrong frame. "Slow" implies a single number that hardware will eventually shrink to zero. The truth is more interesting and more permanent: the costs are a set of trade-offs, and beyond the trade-offs sits a set of theorems that no engineering will ever move.

Start with the trade-offs, because they explain why the field never crowned a winner. Rounds and communication pull against each other. Garbled circuits are constant-round but transmit the entire circuit, so they are bandwidth-hungry. Secret-sharing protocols send little per gate but interact once per layer of multiplication, so their round count grows with depth. Which one wins is not a property of the protocol; it is a property of the network.

On a wide-area link, where each round-trip costs tens of milliseconds, round complexity dominates and constant-round garbling pulls ahead. On a fast local network, bandwidth dominates and the lean secret-sharing protocols win. Add the security-model knobs from Section 2 -- semi-honest versus malicious, honest versus dishonest majority -- and the Yao/GMW/BGW/SPDZ trade-off table above becomes the real cost model. There is no single fastest MPC, only a fastest MPC for a given network and threat model [@ekr-monograph, @mpspdz20].

Now the theorems, which are the deeper half of the story, because they say some of the ideal party's properties are simply unattainable.

A protocol computes a function with *complete fairness* if either all parties receive the output or none do, so no party can learn the answer while denying it to everyone else. This is strictly stronger than *security with abort*, in which a corrupted party may see the output and then quit before the honest parties obtain theirs. *Guaranteed output delivery* is stronger still: the honest parties are assured of the output even if the corrupted parties vanish entirely [@ekr-monograph].

The foundational limit is Cleve's, from 1986. He proved that complete fairness is impossible for general-purpose secure computation at a dishonest majority: no single protocol can fairly compute every function, because for some functions -- fair coin-tossing is the classic witness -- whichever party sends the last message can abort at the decisive moment and bias the outcome [@cleve86].

This is not a gap awaiting a cleverer protocol; it is a theorem. It is exactly why the SPDZ family, which aims at arbitrary circuits, provides security with abort rather than guaranteed output, so that "the protocol just stopped" is an accepted outcome rather than a bug.

Then the story turns, and the turn is the real insight of this section. Cleve rules out a protocol that is fair for every function; he does not rule out fairness function by function. Fairness is a property of the function f, not merely of the majority.

In 2008, Gordon, Hazay, Katz, and Lindell overturned the folklore that nothing is fair without an honest majority. They proved that a broad class of functions -- those with no "embedded XOR," which includes Boolean AND, Boolean OR, and Yao's millionaires' comparison -- can be computed with complete fairness even at a dishonest majority, and they gave an explicit two-party protocol that computes Boolean AND fairly with no honest majority at all [@ghkl08].An "embedded XOR" is a two-by-two block inside the function's truth table whose two diagonals are each constant and differ from one another, the pattern that makes plain XOR the canonical unfair function. AND, OR, and the millionaires' comparison contain no such block, which is precisely why they slip past Cleve's obstruction [@ghkl08].

The fuller map -- which remaining functions are fair, and at what round cost, since some feasibly fair ones demand a super-logarithmic number of rounds -- was charted afterward by Asharov and by Asharov, Beimel, Makriyannis, and Omri. The credit for that characterization belongs to them, not to the 2008 result [@asharov14-fairness, @abmo15-fairness].

Note: The tempting summary, "no function can be computed fairly without an honest majority," is false. Cleve's 1986 theorem forbids only a single protocol that is fair for every function; specific functions with no embedded XOR -- Boolean AND, OR, and the millionaires' comparison -- are completely fair even when every party but one is corrupt [@cleve86, @ghkl08]. General-purpose MPC still settles for security with abort precisely because it must also cover the functions, such as plain XOR, that Cleve's argument genuinely defeats.

The other walls line up behind it. Information-theoretic security and guaranteed output require an honest majority, the perfect t < n/3 of BGW or the statistical t < n/2 of Rabin and Ben-Or with a broadcast channel [@bgw88, @rabin-benor89]. Oblivious transfer is both necessary and sufficient for dishonest-majority secure computation. Kilian proved the sufficiency: OT alone computes anything [@kilian88]. The necessity is the near-trivial converse, since OT is itself a two-party secure computation, so any protocol that computes arbitrary functions can in particular compute OT.

There is also a provable separation in communication cost: information-theoretic MPC must send data that grows with the circuit size, on the order of $\Omega(n \cdot |C|)$, while computational MPC built on threshold fully homomorphic encryption needs communication proportional only to the input and output sizes [@dln-lowerbound, @asharov12-tfhe]. That is not a gap someone will close; it is the price of dropping assumptions, stated as a lower bound. Two more limits round out the list: the output-leakage wall from Section 2, where even a perfect protocol reveals whatever the output implies, and the deployment-era wall, the discrete logarithm under almost every shipped threshold signature, which Shor's algorithm breaks and the NIST post-quantum threshold call targets [@nistir8214c].

Key idea: The trusted party can be simulated arbitrarily well, but which of its ideal properties you keep depends on the function you compute and on how many parties you must distrust. An honest majority buys unconditional security and a guaranteed output. A dishonest majority forces cryptographic assumptions and, for general circuits, surrenders guaranteed output to Cleve's theorem -- yet even there, complete fairness survives for the specific functions that carry no embedded XOR. And no setting hides what the output itself reveals. There is no configuration that keeps every ideal property at once.

That reframes the whole picture. MPC is not "magic total privacy that happens to be slow." It is a provably bounded, trade-off-governed approximation of an ideal that is partly unattainable, function by function, and knowing exactly which part is unattainable is what separates an engineer from a marketer. These walls are permanent. But the frontier in front of them is very much alive, and the sharpest open question is the one a quantum computer will eventually force.

9. Open Problems: The Live Frontier

The theoretical spine of MPC has been settled for decades, which makes its live edges easy to see. Five stand out, and the first is the sharpest.

Post-quantum threshold cryptography. The framework can be quantum-safe, but the deployed keys are not, and closing that gap is genuinely hard. Lattice signatures such as ML-DSA thresholdize awkwardly: their security relies on rejection sampling and carefully bounded noise, and splitting the signing operation across parties without leaking that noise, or aborting too often, is an open engineering problem. This is the explicit target of the NIST call, which places threshold ML-DSA in scope as an invited submission rather than a finished standard [@nistir8214c, @nist-mptc].

Note: The most consequential open problem is not making MPC faster. It is making deployed threshold signatures quantum-safe. Today's custody keys rest on the discrete logarithm; a lattice-based threshold signature that is as efficient and as easy to implement as FROST does not yet exist. That is the gap NIST is now inviting the field to fill [@nistir8214c].

Collapsing the offline phase. SPDZ's throughput is bounded by how fast it can manufacture triples. Silent OT and pseudorandom correlation generators shrink the preprocessing communication toward sublinear, but their local computation cost and the exact parameterization of their underlying assumption remain active research [@silentot19].The learning-parity-with-noise assumption behind silent OT is itself a candidate post-quantum assumption, which is why the modern offline phase and the post-quantum question are quietly related [@silentot19].

MPC at scale. Pushing to many parties and billion-gate circuits, with overhead approaching that of insecure computation, is a moving target. Honest-majority protocols now run close to the $\Omega(n \cdot |C|)$ communication lower bound, so further gains have to come from assumptions or from restructuring the computation rather than from cleverer sharing [@dln-lowerbound, @asharov12-tfhe].

Resilient and asynchronous MPC. Delivering guaranteed output over real adversarial networks, where messages are delayed or dropped and parties may vanish, is possible only with an honest majority, because Cleve's theorem forbids it otherwise. Building practical asynchronous protocols that keep that guarantee is ongoing [@cleve86].

Standardization and interoperability. RFC 9591 gave FROST a single interoperable definition, but custody vendors still ship mutually incompatible threshold-ECDSA stacks. Whether the NIST effort yields interoperable post-quantum threshold standards, the way the IETF is standardizing private analytics through the Distributed Aggregation Protocol draft, is an open question with real commercial stakes [@rfc9591, @ietf-dap].

Finally, the synthesis this series has been building toward. The three privacy technologies are complementary, not competing. Fully homomorphic encryption outsources computation on a single party's ciphertext. Zero-knowledge proofs establish correctness without revealing the witness. MPC splits trust across parties. The interesting systems compose them: MPC for input privacy, zero-knowledge for correctness against active cheaters, and homomorphic encryption to offload heavy computation. Threshold FHE already lives at exactly that seam, using MPC to distribute the FHE decryption key so that no party can unilaterally decrypt [@asharov12-tfhe]. The frontier is not any one of these techniques winning; it is learning to wire them together.

The research is thrilling. But you have a system to ship this quarter, so here is how to choose today, without rolling your own cryptography.

10. A Practical Guide: Which Primitive, Which Library

The decision is usually simpler than the theory. Match your problem to a construction, then reach for an audited implementation of it. Never write the protocol yourself.

flowchart TD A{"What do you need?"} --> B{"Only sign or decrypt?"} B -->|Yes| T[Threshold signatures: FROST, CGGMP, or DKLs] B -->|No| P{"Just an intersection or an aggregate?"} P -->|Set intersection| PSI[Private set intersection] P -->|Aggregate over many clients| AGG[Prio or DAP, or DPFs for heavy hitters] P -->|A general function| C{"How many parties?"} C -->|Two parties on a WAN| G[Garbled circuits with half-gates] C -->|Many parties on a LAN| D{"Honest majority available?"} D -->|Yes| E[BGW-style, no assumptions] D -->|No| F[SPDZ family, malicious at a dishonest majority]

The rules behind the fan are short enough to memorize. If two parties must jointly evaluate a mostly-Boolean function across a high-latency link, use garbled circuits with half-gates, upgraded to authenticated garbling if the adversary may be malicious [@halfgates15, @wrk17-authgarbling]. If many parties compute an arithmetic function on a fast network and you need malicious security, use the SPDZ family [@spdz12, @mpspdz20]. If you have an honest majority and want no cryptographic assumptions, a post-quantum-safe framework, or guaranteed fairness, use a BGW-style protocol [@bgw88]. And if all you need is to sign or decrypt, use a threshold signature, FROST for Schnorr and EdDSA, CGGMP or DKLs for ECDSA, and do not build a general circuit for a job the specialized protocol does in milliseconds [@rfc9591, @cggmp20, @dkls19].

Two specialized shortcuts finish the list. If two parties need only the intersection of their sets, or an aggregate over it, reach for private set intersection -- the flagship deployed 2PC, behind privacy-preserving ad-conversion measurement -- rather than a hand-rolled general circuit [@psi-ion20]. And for aggregate statistics across many clients with no trusted aggregator, use secret-shared reports in the Prio and DAP style, or function secret sharing and DPFs when you need private heavy hitters as in Poplar [@prio17, @poplar21, @fss-bgi15].

Situation	Reach for	Audited implementation
Two parties, high-latency link, Boolean function	Garbled circuits (half-gates; authenticated garbling if malicious)	EMP-toolkit
Many parties, arithmetic, LAN, malicious security	SPDZ family	MP-SPDZ
Honest majority; no assumptions or fairness wanted	BGW-style (Shamir or replicated three-party)	MP-SPDZ honest-majority protocols
Only need to sign or decrypt	Threshold signatures (FROST, or CGGMP/DKLs for ECDSA)	cb-mpc, FROST implementations
Two parties, learn only a set intersection or an aggregate over it	Private set intersection (PSI)	Audited PSI protocols
Private aggregate stats across many clients, no trusted aggregator	Prio/DAP shares; FSS/DPFs for heavy hitters	libprio, DAP, Poplar
One server computes on your single ciphertext	Fully homomorphic encryption (Part 1)	See Part 1
Prove a computation ran correctly	Zero-knowledge proofs (Part 2)	See Part 2

The mature, audited frameworks are worth naming: MP-SPDZ spans more than thirty protocols across the trade-off space [@mpspdz-github], EMP-toolkit is a reference for semi-honest and malicious garbling [@emp-toolkit], and Fairplay, back in 2004, was the first general-purpose secure two-party system to leave the blackboard [@fairplay04].

Note: Three rules save you from the failure modes this series keeps circling. First, a protocol proven only semi-honest is worthless against an attacker who is willing to deviate; match the security model to your real adversary. Second, nonce and randomness hygiene is catastrophic to get wrong in threshold signing, so use vetted code paths. Third, keep GG18 and GG20 deployments patched: the TSSHOCK class of bugs lives in the range proofs bolted around the protocol, not in the protocol's core idea, and an unpatched library leaks keys even though the theorem is sound [@cve-2023-33241].

Suppose you run custody and want five of eight operators to authorize each transfer, with no server ever holding the key. Walk the fan. Do you only need to sign? Yes. So you do not build a general circuit at all. The asset uses ECDSA, so you choose a threshold-ECDSA protocol, CGGMP if you want identifiable abort and proactive refresh, or a DKLs OT-based protocol if you want to avoid Paillier machinery entirely, a line tracked on its public project page [@dkls-info]. You run distributed key generation so the key is born as eight shares, you require any five to sign, and you deploy an audited library rather than your own. The output is an ordinary ECDSA signature the blockchain verifies with the normal public key, and no box ever held the private key [@cggmp20, @dkls19].

One decision table cannot answer every worry, so here are the questions readers ask most, and the misconceptions most worth retiring.

11. Frequently Asked Questions

No. Fully homomorphic encryption has one server compute on your single ciphertext, so trust rests on a hardness assumption. MPC splits the trust across several parties, so privacy holds as long as too few of them collude. They are different tools for different trust models, and they compose rather than compete [@lindell21-cacm]. No, and this is the most common misconception. MPC hides the inputs; the output is revealed to whoever is entitled to it, and the output can itself leak. If two parties compute their sum, each recovers the other's value by subtraction. Choosing a function whose output says too much is a design error no protocol can repair [@lindell21-cacm]. No. A Shamir backup is reconstruct-once: you gather the shares and rebuild the whole key to use it. An MPC signing key is never-reconstruct: it is used repeatedly without ever being assembled anywhere. That difference is the entire security claim of MPC custody [@rfc9591, @cbmpc]. The framework can be. BGW is information-theoretic and needs no computational assumption at all. But most deployed threshold signatures rest on the discrete logarithm, which Shor's algorithm breaks. NIST's IR 8214C places threshold ML-DSA in scope as an invited submission; it is a call for schemes, not a standardized scheme [@nistir8214c]. "Slow" is the wrong frame. The costs are trade-offs among rounds, bandwidth, and trust model, and the right choice depends on your network. Threshold signing in particular is millisecond-scale and ships in custody wallets today; general-purpose MPC has a cheap online phase after preprocessing [@ekr-monograph, @mpspdz20]. An honest majority is required only for information-theoretic security or a guaranteed output, which BGW gives at `t < n/3`; SPDZ-family protocols tolerate up to `n-1` malicious parties, a full dishonest majority, but only with security-with-abort, where a cheater can halt the protocol yet not forge the result [@bgw88, @spdz12]. Fairness is subtler. Complete fairness for *general* computation is impossible without an honest majority (Cleve), but fairness is a property of the function: specific functions with no "embedded XOR" -- Boolean AND, OR, and the millionaires' comparison -- are completely fair even at a dishonest majority, so the common claim that "no function is ever fair without an honest majority" is simply false [@cleve86, @ghkl08]. No. The fragility lives in the integration, not the theorem. TSSHOCK and BitForge extracted full keys from real wallets, but the flaw was a range-proof implementation bug, not a break of threshold ECDSA. Use audited libraries, keep nonce handling vetted, and patch GG18 and GG20 deployments [@cve-2023-33241].

The Party Nobody Had to Be

Return to the two hospitals and the billion-dollar transfer. The instinct in both cases was to appoint a trusted party, and the whole article has been an argument that you can get everything that party would have given you without anyone ever being it.

Read the evidence back in order. Kilian proved that one humble primitive, oblivious transfer, is enough to compute anything securely, which turned "invent a protocol per problem" into "build good OT and wire it up" [@kilian88]. Yao's garbled circuits, GMW, and BGW then instantiated that promise three different ways, trading rounds against bandwidth against trust assumptions so completely that all three still ship.

The preprocessing model and SPDZ made malicious security at a dishonest majority cheap, by authenticating every share so a single check catches a cheater [@spdz12]. And threshold cryptography is the deployed special case: fix the function to sign or decrypt, generate the key by distributed key generation, and the key exists only as a capability the group can exercise, never as a value in any box [@rfc9591, @cbmpc].

The honesty is the other half of the argument. MPC hides inputs, not outputs. Complete fairness for general-purpose computation is impossible at a dishonest majority, so a cheater can always halt, even though specific no-embedded-XOR functions stay fair even there. Information-theoretic security demands an honest majority. And almost every deployed threshold signature still rests on the discrete logarithm, which is why NIST's post-quantum threshold call, a call and not yet a standard, is the live frontier [@nistir8214c]. A companion post, "How Secure Multiparty Computation Would Break," presses on exactly those seams, and the series through-line remains that MPC, zero-knowledge, and homomorphic encryption are three complementary ways to compute on data that is never decrypted.

The trusted party can be simulated arbitrarily well. Which of its ideal properties you keep depends on the function you compute and how many parties you must distrust, and that, not speed, is the real shape of secure computation.