The MPC Guarantee, Defined: Computing Without Revealing Inputs, and the Adversary Models

Abstract

This opening article defines secure multi-party computation (MPC) precisely. MPC lets several parties, each holding a private input, jointly compute an agreed function so that everyone learns the correct output and nothing about the others' inputs beyond what the output itself implies. It grounds the definition in the ideal-versus-real paradigm: a protocol is secure if running it reveals no more than an imaginary trusted third party would, one who collects everyone's inputs, computes the function, and returns only the output. Security means the real protocol, with no such trusted party, emulates that ideal — a simulator argument echoing the zero-knowledge series. It states the two guarantees, input privacy and correctness, and then develops the adversary models that determine how hard security is to achieve: the semi-honest (honest-but-curious) adversary who follows the protocol but mines the transcript, the malicious adversary who deviates arbitrarily, and the covert middle ground, together with the corruption threshold of honest-majority versus dishonest-majority settings. It closes on the feasibility landmark — that any function can in principle be computed securely — and the AI stakes: MPC is the third leg of confidential computing alongside zero-knowledge and homomorphic encryption, enabling several organizations to compute over their combined data without pooling it. The theme: MPC's guarantee is defined by emulating a trusted party, and its difficulty by which adversary must be tolerated.

Secure multi-party computation solves a problem that sounds impossible: several parties, each guarding a private input and trusting none of the others, want to jointly compute a function of all their inputs and learn the result — without any party revealing its input to anyone. Hospitals computing a statistic across their patient records, companies finding common customers, or agents combining private signals all want the answer without exposing the data. This article defines exactly what that guarantee means, through a comparison to an ideal trusted party, and lays out the adversary models that decide how hard it is to achieve — the foundation for the constructions in the rest of the series.

The ideal-world definition

The clean way to define MPC security is to compare the real protocol to an ideal one. Imagine an incorruptible trusted party: every participant privately hands it their input, it computes the agreed function, and it returns only the output to everyone. In this ideal world nothing leaks but the result — no participant sees another's input, and the trusted party forgets everything else. This is the gold standard of what a joint computation should reveal, and it is obviously secure because the trusted party by construction discloses nothing beyond the output.

A real MPC protocol has no trusted party; the participants exchange messages among themselves. It is defined to be secure if it emulates the ideal world — if whatever an adversary can learn or do by attacking the real protocol, it could also learn or do in the ideal world with the trusted party. Formally, this is a simulator argument, the same device as in zero-knowledge: for any real-world attack there exists a simulator that produces an indistinguishable outcome in the ideal world, so the real protocol leaks no more than the ideal one, which leaks only the output.

This ideal-versus-real framework is powerful because it defines security by a single, intuitive standard rather than a checklist of specific attacks. Anything the ideal trusted party would not reveal, a secure protocol does not reveal either. It also makes the guarantee composable and precise: to prove a protocol secure, one exhibits the simulator, exactly as one exhibits a simulator to prove zero-knowledge. The entire field rests on constructing real protocols that provably emulate this ideal.

A secure protocol with no trusted party emulates an ideal trusted party that returns only the output.

\[\text{Security: } \mathsf{REAL}_{\pi, \mathcal{A}}(x_1, \dots, x_n) \;\approx\; \mathsf{IDEAL}_{f, \mathcal{S}}(x_1, \dots, x_n)\]

\[\text{Ideal party computes } y = f(x_1, \dots, x_n) \text{ and returns only } y\]

What is guaranteed

Two properties follow from emulating the ideal world. Input privacy means no party learns anything about another's input beyond what the output necessarily reveals — the transcript of messages a party sees can be simulated from its own input and the output alone, so it carries no extra information. Correctness means the output really is the agreed function of the true inputs; a party cannot cause the computation to produce a wrong result that the honest parties accept. Together they say: the right answer, and nothing but the answer.

The caveat in input privacy is important and often misunderstood. MPC hides the inputs, but the output itself may reveal information about them — that is unavoidable and by design, because the output is what the parties agreed to learn. If two companies compute the size of their customer overlap, they learn that number, which constrains what the inputs could be; MPC guarantees they learn nothing more than that agreed number, not that the number reveals nothing. Choosing a function whose output leaks little is a separate design concern layered on top of the MPC guarantee.

These guarantees are exactly the confidential-computing complement to the other two legs. Zero-knowledge proves a statement about a computation without revealing a witness; homomorphic encryption computes on one party's encrypted data; MPC computes over several parties' private data at once, revealing only the joint result. The distinguishing feature is the multiplicity of mutually distrustful data owners, and input privacy plus correctness are the precise promises MPC makes to all of them simultaneously.

Emulating the ideal world gives input privacy and correctness, revealing only the agreed output.

The adversary models

How hard it is to build a secure protocol depends entirely on what the adversary is allowed to do, and there is a spectrum of models. The semi-honest, or honest-but-curious, adversary follows the protocol exactly but tries to infer others' inputs from everything it legitimately sees. Security against a semi-honest adversary is the easier goal and is often enough when participants are trusted to run the right software but should not learn each other's data — a common situation among cooperating but competing organizations.

The malicious, or active, adversary is far stronger: it may deviate from the protocol arbitrarily — sending wrong messages, aborting, or manipulating the computation to learn inputs or force a wrong output. Security against a malicious adversary is harder and costlier, requiring extra machinery such as zero-knowledge proofs that each party followed the protocol, or authenticated secret shares. Between the two sits the covert model, where a cheating party is not prevented but is caught with high probability, deterring misbehavior at lower cost than full malicious security.

Orthogonal to behavior is the corruption threshold: how many parties the adversary controls. Many efficient protocols assume an honest majority — that more than half the parties are honest — which enables strong guarantees including guaranteed output. Others tolerate a dishonest majority, even all-but-one corrupted, but then cannot guarantee output delivery, only that nothing leaks. Every MPC protocol is characterized by this pair — which adversary behavior and what corruption threshold it withstands — and reading those two parameters is the first thing to do when evaluating one.

Semi-honest adversaries follow the protocol, covert ones are caught if they cheat, and malicious ones deviate freely.

Feasibility, and the AI stakes

The foundational result of the field is that secure computation is universally possible: any function that can be computed at all can be computed securely by a multi-party protocol, a landmark established by the garbled-circuit and GMW constructions of the 1980s that later articles develop. This is a remarkable statement — it says there is no computation that inherently requires exposing the inputs, only ones that are more or less expensive to compute privately. The research program since has been about efficiency, not possibility: making secure computation fast enough to use.

Efficiency is exactly where the adversary model bites, because stronger guarantees cost more. Semi-honest, honest-majority protocols can be quite practical; malicious-secure, dishonest-majority protocols are much heavier, mostly in communication rather than computation, since the parties exchange many rounds of messages. This communication cost is the signature expense of MPC and the main axis on which it is compared to the other confidential-computing approaches, which trade instead in computation (homomorphic encryption) or hardware trust (trusted execution environments).

For AI, MPC is the third leg of confidential computing and the one built for collaboration among data owners. It lets several organizations jointly train a model or compute a statistic over their combined private datasets without any of them pooling or exposing raw data — hospitals building a shared diagnostic model, banks computing a joint fraud signal, agents combining private observations into a shared decision. Where homomorphic encryption serves one client and one server, and zero-knowledge proves one party's computation, MPC serves the many-distrustful-parties setting that collaborative AI demands. The precise guarantee — emulate a trusted party, reveal only the output, against a specified adversary and corruption threshold — is what makes such collaboration safe, and it is the definition on which the concrete protocols of the rest of this series are built.

📌

The definition, and the two parameters. MPC is secure if it emulates an ideal trusted party that returns only the output, giving input privacy and correctness. Its difficulty is set by two parameters: the adversary model (semi-honest, covert, or malicious) and the corruption threshold (honest majority or dishonest majority). Read both to understand any protocol.

Key takeaways

MPC lets several distrusting parties jointly compute a function of their private inputs, learning the correct output and nothing else about the inputs.
Security is defined by the ideal-versus-real paradigm: the protocol must emulate an incorruptible trusted party that returns only the output, proven via a simulator.
The two guarantees are input privacy (no leakage beyond the output) and correctness (the output is the true function of the real inputs).
Input privacy does not stop the output itself from constraining the inputs — choosing a low-leakage function is a separate concern.
Difficulty is set by the adversary model — semi-honest, covert, or malicious — and the corruption threshold — honest majority or dishonest majority.
Any function can in principle be computed securely; MPC is the third leg of confidential AI, enabling collaboration over combined private data without pooling it.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

✅Evaluating an MPC protocolchecklist

The parameters that define its guarantee.

What adversary model does it withstand — semi-honest, covert, or malicious?
What corruption threshold — honest majority or dishonest majority?
Does it guarantee output delivery, or only privacy on abort?
What does the agreed output itself reveal about the inputs?
What is its communication cost (rounds and bandwidth), the signature MPC expense?

🚀The MPC mental modelquickstart

Three facts to hold onto.

Secure means it emulates a trusted party that returns only the output.
Guarantees: input privacy and correctness.
Difficulty scales with the adversary model and corruption threshold.

🔒Collaborative-computation stancepolicy

A stub recording the MPC requirements.

mpc_deployment:
  guarantee: emulate_trusted_party
  properties: [input_privacy, correctness]
  adversary_model: [semi_honest, covert, malicious]
  corruption_threshold: [honest_majority, dishonest_majority]
  output_leakage: review_function_choice
  cost_axis: communication

Illustrative documentation template, not a product config.

Glossary

Secure multi-party computation (MPC): A protocol letting several parties jointly compute a function of their private inputs, revealing only the output.
Ideal-versus-real paradigm: The definition of MPC security: a real protocol is secure if it emulates an ideal trusted party that returns only the output.
Input privacy: The guarantee that no party learns anything about another's input beyond what the output necessarily implies.
Semi-honest adversary: An honest-but-curious party that follows the protocol but tries to infer others' inputs from what it sees.
Malicious adversary: An active party that may deviate from the protocol arbitrarily to learn inputs or force a wrong output.
Corruption threshold: How many parties the adversary controls; honest-majority and dishonest-majority settings give different guarantees.
Covert adversary: A middle model in which a cheating party is not prevented but caught with high probability, deterring misbehavior.