SMPC or How to Compute on Data You Can't See

Let’s say you and two friends are sitting at a pub. You all want to figure out your average salary. The problem is that nobody wants to actually reveal what they make.

You could hire a trusted accountant, tell them your salaries, and have them calculate it. But what if you don’t want to trust a third party?

There is a mathematical workaround. If your salary is £100,000, you don’t say that number out loud. Instead, you chop it into three completely random pieces that add up to £100,000. You might pick £400,000, minus £500,000, and £200,000. You keep one piece for yourself. You hand the second piece to friend A. You hand the third piece to friend B.

Your friends do the exact same thing with their own salaries. They chop them up and pass them around.

Now, everyone is holding three completely random numbers. You each add up the three numbers in your own hands. The result is pure mathematical noise. It means absolutely nothing and reveals nothing about anyone’s real income.

Finally, the three of you say your meaningless totals out loud. When you add those three final numbers together, all the randomness perfectly cancels out. You are left with the exact combined total of your actual salaries. You divide by three to get the average. You found the exact answer without ever seeing the underlying data.

This is not a parlor trick. It is the foundation of a cryptographic framework called Secure Multi-Party Computation, or SMPC.

For the entire history of software engineering, we have accepted a basic premise. To run logic on data, the computer has to be able to see the data in plaintext. This creates massive structural problems for organizations that want to collaborate but cannot legally or commercially share their databases.

Think about government departments trying to verify if an applicant is eligible for a cross-departmental service. Or two banks trying to figure out if they are both investigating the same person for fraud. The traditional solution is to build a massive, centralized data lake. That approach is a nightmare for privacy, compliance, and security.

SMPC allows us to break that basic premise. It allows multiple servers to compute functions on encrypted inputs.

Under the hood, SMPC frameworks take standard data and convert it into polynomials using techniques like Shamir’s Secret Sharing. The data is hidden as the y-intercept of a graph. Points on that graph are distributed to the participating nodes.

Because of the rules of finite field arithmetic, those nodes can run calculations on their individual points. They can add them together or multiply them. When they are done, the nodes combine their computed points. This reveals a brand new polynomial containing the final answer, like a simple “true” or “false”, without ever exposing the raw inputs that created it.

This sounds like magic, but it comes with a brutal engineering cost.

You are trading compute speed and network bandwidth for absolute data privacy. Operations that take a microsecond on a normal CPU become incredibly heavy. While addition is easy in SMPC, multiplication requires the nodes to constantly talk back and forth over the network to keep the math aligned. This means your processing speed is entirely bottlenecked by network latency.

You would never use SMPC to run a standard web application or a high-volume database. It is strictly a tool for the edges of your architecture.

If you are building distributed systems where different sovereign entities need to interact, SMPC acts as a highly secure bridge. You keep your core applications running normally on local servers. You only invoke an SMPC microservice when you need to cross a trust boundary and ask a specific, high-stakes question of a partner network.

We are finally moving past the idea that data must be pooled to be useful. With SMPC, we can keep the data locked down and just share the computation.