Multi-party computation applied to security

Three colleagues want to know whether, on average, they earn more than the market. None of them wants to tell the others their own salary. The obvious solution is to hand the numbers to a trusted person, who does the math and discloses only the average. But what if there is no one all three trust?

Secure multi-party computation (MPC) is cryptography’s answer to this problem. It lets several parties compute a result together without any of them seeing the others’ data. This article explains the idea, shows how it is used to protect keys and signatures and where its limits lie.

What multi-party computation is

NIST, the US standards institute, defines the technique as the joint computation of a function over data distributed among several parties, without each one revealing its data (NIST, Privacy-Enhancing Cryptography). The institute considers it one of the main techniques of interest in its privacy-enhancing cryptography project (NIST, MPC and threshold schemes).

A useful way to think about it: imagine a perfect intermediary who receives everyone’s data, does the computation, announces the result and forgets everything. Multi-party computation replaces that intermediary with a protocol, a script of messages exchanged among the participants themselves. This is the image used in the 1987 paper that generalized the technique, which describes the “extra trusted party” that the protocol makes unnecessary (Goldreich, Micali and Wigderson).

Where it came from: the millionaires’ problem

The question was posed in 1982 by computer scientist Andrew Yao. Two millionaires want to know which of them is richer without learning anything else about each other’s fortune. How should they conduct that conversation (Yao, 1982)?

Yao treated the case as an example of a general problem: several people, each with a secret value, want to compute a function of those values without giving away more information than necessary. In that same paper he pointed to applications such as secret voting, private database queries and negotiation.

In 1987, Oded Goldreich, Silvio Micali and Avi Wigderson showed that any function can be computed this way, with an efficient algorithm, as long as the majority of participants are honest. They also observed that, without an honest majority, some problems have no efficient solution (Goldreich, Micali and Wigderson). This condition, how many participants can cheat without breaking security, comes back every time a real system is evaluated.

How it works, in simplified form

One of the most widely used tools is secret sharing: splitting a piece of data into pieces, called shares, so that each piece alone reveals nothing.

Back to the three colleagues. A teaching example prepared by our newsroom:

1. Ana earns 9. She draws two random numbers, say 25 and -4, and computes the third so that the sum equals 9: 9 - 25 - (-4) = -12. She keeps one share and hands the other two to her colleagues, one each.
2. Bruno and Carla do the same with their salaries.
3. Each one adds up the shares they hold and announces only that partial sum.
4. The sum of the three partial sums is the total of the salaries. Divided by three, it gives the average.

No single share says anything, because it is a random number. All that is revealed is the total. Real protocols use modular arithmetic and more elaborate techniques to compare, multiply and deal with dishonest participants, but the logic is the same: computing on pieces that, on their own, mean nothing.

In 1979, Adi Shamir published a more flexible method, the (k, n) threshold scheme. The secret is split into n shares. Any k of them reconstruct the secret; with k - 1 or fewer, all possible values remain equally likely (Shamir, 1979).

Application to security: keys that are never whole

Shamir himself pointed out the problem the technique solves. Storing a cryptographic key in a single place is risky: a failure, a death or sabotage makes it inaccessible. Making several copies solves that, but multiplies the chances of a leak (Shamir, 1979).

The paper’s example is a company that signs checks digitally. Instead of giving the key to each executive, each receives a share, and any three can sign. A disloyal executive would need at least two accomplices to forge a signature.

Modern threshold cryptography goes one step further. It applies the principles of multi-party computation so that the parties produce a signature, decrypt a message or generate a key together, without ever needing to reassemble the whole key. NIST describes the goal as a “secure distribution of trust” in the operation of cryptographic primitives (NIST, threshold cryptography).

In practice, this changes the threat model:

• An attacker needs to compromise several parties, not a single server, to steal or use the key.
• Losing some shares is not fatal, as long as enough remain to reach the threshold.
• No single person can act alone, which protects against insider fraud.

In crypto assets, this design appears in corporate key custody and in some wallets. MPC’s role in professional custody is covered in institutional crypto custody, and the difference in who controls the keys, in custodial and non-custodial wallets.

NIST is preparing standards

NIST runs a project dedicated to multi-party threshold schemes. It covers signatures, public-key encryption and decryption, key generation, fully homomorphic encryption and related techniques such as zero-knowledge proofs (NIST, threshold cryptography).

According to the project page, consulted on October 8, 2026, the public call for proposals (NIST IR 8214C) had its final version published on January 20, 2026, and the process was continuing with proposal presentation phases throughout 2026. As of that date, the page does not indicate a final NIST standard for these schemes.

A real case: the sugar beet auction in Denmark

The first large-scale practical application of the technique, according to its authors, took place in January 2008 (Bogetoft et al.).

Danish farmers needed to trade sugar beet production contracts among themselves. The sole buyer was Danisco. Bids reveal each producer’s economic situation, and the farmers would not accept Danisco as auctioneer, because it could use that information in renegotiations.

The solution was an auction in which the auctioneer role was split among three parties: Danisco, the growers’ association (DKS) and the SIMAP research project. Each bid left the farmer’s computer encrypted and split. Together, the three parties computed the market clearing price without any of them seeing an open bid. There were 1,229 bidders.

The paper records a benefit that goes beyond the technique: since no one needed to see the bids, there was no need to negotiate who would have access to them or who would be liable for a leak.

Limits and risks

Multi-party computation reduces the trust required, but does not eliminate it. In our newsroom’s assessment, based on the sources above, the points to watch are:

• Collusion threshold. Security holds as long as the number of dishonest parties stays below the protocol’s limit. If the parties are, in practice, controlled by the same company or run on the same infrastructure, the split is only apparent.
• Adversary model. Some protocols only protect against “curious” parties, which follow the rules but try to learn something. The Danish auction, for example, adopted this model, because none of the three parties suspected an active attack by the others. Protecting against those who deviate from the script requires extra mechanisms, such as zero-knowledge proofs.
• The result is also informative. In the millionaires’ problem, the loser learns that the other has more money. The technique protects the inputs, not what can be inferred from the answer.
• Performance. The parties exchange many messages. The cost is higher than doing the same computation on a single server.
• Implementation. A protocol that is secure on paper can fail because of a coding error, a weak random number generator or poor share management. The lack of an official standard makes it harder to compare solutions.
• System endpoints. If the computer of the person typing the password or approving the operation is compromised, the protocol’s math doesn’t help.

Key takeaways

• Multi-party computation replaces the trusted intermediary with a protocol: the parties compute together and only the result appears.
• In security, it allows keys to be split so that no single person or server can sign, decrypt or lose everything.
• Real protection depends on how many parties can collude, who controls each share, the quality of the implementation and what the result itself reveals. NIST is still working on standards for these schemes.