# MP-SPDZ: one program, many MPC protocols, so you can compare them > MP-SPDZ is a C++ framework for secure multi-party computation whose purpose is comparison. The same program can be run under dozens of protocols, from MASCOT and SPDZ2k to Rep3, Yao's garbled circuits and the dealer model, across honest and dishonest majority and semi-honest and malicious corruption. The README is explicit that it has not had the security review that production code needs. **data61/MP-SPDZ** — Versatile framework for multi-party computation - Repository: https://github.com/data61/MP-SPDZ - Stars: 1,197 · Forks: 372 - Language: C++ - License: NOASSERTION - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/data61-mp-spdz ## The goal is comparison, and the README says so first MP-SPDZ is software to benchmark various secure multi-party computation protocols in a variety of security models, and the preface states the primary aim plainly: to run the same computation in various protocols in order to compare the performance. That framing decides everything else about the project. It is not a library you wrap around one protocol, and it is not a product with a service around it. It is an experimental platform where the same program, written once in a high level language, runs under many different cryptographic protocols, and the interesting output is the comparison. The underlying technologies span secret sharing, homomorphic encryption and garbled circuits, so the protocols in the matrix are not variations on one idea. They differ in how the secret is shared, whether the parties must be semi-honest or may be actively malicious, and how the computation is arranged. The design is described in a paper, MP-SPDZ: A Versatile Framework for Multi-Party Computation, at eprint 2020/521, published at ACM CCS 2020, and the project asks academic users to cite it. One line in the preface deserves to be read twice by anyone considering production use: all the protocols in the matrix are fully implemented, but that does not mean the software has undergone a security review as should be done with critical production code. The project is a research tool with an explicit warning attached, and that is a statement of fact rather than a hedge. ## The protocol matrix is the real interface of the project The protocols table in the README is the thing to understand before anything else, because it tells you what is available and on what terms. The rows are security models. Malicious with a dishonest majority, covert with a dishonest majority, semi-honest with a dishonest majority, malicious with an honest majority, semi-honest with an honest majority, malicious with an honest supermajority, and semi-honest with a dealer. The columns are the arithmetic. Modulo prime and GF(2^n), modulo 2^k, binary secret sharing, and garbling. The README explains that modulo prime and modulo 2^k are the two settings that allow integer-like computation, and that for k equals 64 the latter corresponds to the computation available on the widely used 64-bit processors. GF(2^n) denotes Galois extension fields of order 2^n, which are different from computation modulo 2^n, since every element has an inverse. The populated cells tell you which protocol covers which combination. Malicious with a dishonest majority gives you MASCOT, LowGear and HighGear for the prime setting, SPDZ2k for mod 2^k, Tiny and Tinier for binary secret sharing, and BMR for garbling. The honest majority rows are dominated by Shamir, Rep3, PS, SY, Rep4, Brain, CCD and, in the semi-honest case, ATLAS, Astra and Trio, the last of which belong to the protocols with function-dependent preprocessing. The covert row has CowGear and ChaiGear, and the dealer row offers the Dealer protocol across the arithmetic columns. Read as a whole, the matrix says that the more adversarial the model, the narrower your arithmetic choices become, and that the most capable protocols are not available everywhere. ## Three ways to run the tutorial, and the binary route is the quick one The README gives a short path for each supported platform, and the first one runs from a downloaded distribution. For a binary distribution on Linux or a source distribution on macOS, you need a Linux distribution originally released 2019 or later with glibc 2.28, or macOS High Sierra or later, plus Python 3 and basic command line utilities. On macOS the project recommends downloading directly from GitHub because of the way dependencies are fetched with git. Unpack the distribution and run this from the top folder. ```bash Scripts/tldr.sh echo 1 2 3 4 > Player-Data/Input-P0-0 echo 1 2 3 4 > Player-Data/Input-P1-0 Scripts/compile-run.py -E mascot tutorial ``` The same tutorial from a source checkout needs Git for the clone, a working toolchain and the requirements. On Ubuntu the project suggests a package list. ```bash sudo apt-get install automake build-essential clang cmake git libboost-dev libboost-filesystem-dev libboost-iostreams-dev libboost-thread-dev libgmp-dev libntl-dev libsodium-dev libssl-dev libtool python3 ``` On macOS the same dependencies come from brew, and the project offers an automatic download if brew is not found. Then it is one make target and the same three commands. ```bash make setup echo 1 2 3 4 > Player-Data/Input-P0-0 echo 1 2 3 4 > Player-Data/Input-P1-0 Scripts/compile-run.py mascot tutorial ``` The Docker route builds an image for a single machine target and runs the tutorial inside it. ```bash docker build --tag mpspdz:mascot-party --build-arg machine=mascot-party.x . docker run --rm -it mpspdz:mascot-party ./Scripts/compile-run.py mascot tutorial ``` All three run the tutorial with two parties and malicious security. On hardware with several cores and gigabytes of RAM, the README suggests building the machine binary ahead of time to save the last step, with make -j8 mascot-party.x. ## Two parties, one line of input each, and a protocol name on the command line The mechanics of a run are worth understanding, because the same shape applies to any program you write. Each party has its own input file under Player-Data, named for the party and the program slot, so Input-P0-0 for party zero and Input-P1-0 for party one. The tutorial writes a line of four integers into each, and those are the private inputs the protocol will protect. The compiler is invoked with the protocol and the program. In the binary distribution route the flag is -E, as in compile-run.py -E mascot tutorial, while the source route uses the same script without it. The protocol name is not decoration: it selects the cryptographic protocol, and the project asks issue reporters to say which protocol they used, because the differences between the protocols are considerable. The compiler can also point you at the literature. Many computations rely on several papers, and --papers makes the compiler output links to relevant reading. ```bash ./compile.py --papers -E Scripts/compile-run.py --papers ``` There is a systematic overview in the documentation, and the documentation also has a troubleshooting section that the README asks you to check before filing an issue, alongside the issue tracker and an email address. The project asks for complete code examples in issues, since incomplete code usually cannot be reproduced, and the difference between protocols means a report without the protocol name is often unreproducible too. ## A Python compiler sitting in front of a C++ machine layer The repository structure shows the two halves of the system. The compiler side is Python. There is compile.py at the root, a Compiler/ directory, and setup.py, which packages the compiler as a distribution named mp-spdz-compiler at version 0.1.0, with the Compiler and Compiler.* packages included. That means the compiler can be installed and used on its own, which matters if you want the front end without the rest. The execution side is C++ and is organised by technique and by machine. Machines/ holds the protocol implementations, Protocols/ holds the shared building blocks, Processor/ holds the virtual machine layer that executes the compiled program, Math/ the arithmetic, Networking/ the transport, GC/ the garbled circuit code, Yao/ the Yao style protocols, BMR/ the garbling scheme, FHE/ and FHEOffline/ the homomorphic encryption parts, OT/ the oblivious transfer, ECDSA/ the signature support, and Tools/ and Utils/ the shared helpers. Programs/Source holds the programs, including the tutorial, and Scripts/ holds the driver scripts such as compile-run.py and tldr.sh. The Makefile is the build map, and it shows the shape of the dependency graph. The CONFIG file at the root is included by the Makefile and holds the feature switches, including whether to use the oblivious transfer variants, the shared and static library forms of the crypto tools, and whether to build with AVX. Azure Pipelines handles the continuous integration, and deps/ carries the vendored dependencies that the Makefile compiles as static libraries. The practical implication is that a protocol is not one file. Adding or changing one touches the machine layer, the protocol layer and the processor interface, which is why the project is a framework rather than a toolbox. ## The boundary the project draws for itself There is one limitation that overrides all the others, and the project states it in the preface rather than burying it. The software has not undergone a security review as should be done with critical production code. Every protocol in the matrix is fully implemented, and the implementations are the ones used to produce the comparisons the project exists for, but fully implemented is not the same as audited. If you are computing something whose disclosure would harm someone, the project is telling you that the burden of review is on you. There is a second, softer limitation. The tool is built to compare protocols, so its defaults and its ergonomics are aimed at experiments: you name a protocol on the command line, you run several, you compare. A deployment where one protocol is chosen once and run for years is a use the project does not appear to be designed around, and the surface area of configuration it expects you to touch is the matrix itself rather than a single opinionated setup. The third limitation is arithmetic. Choosing between a mod prime protocol and a mod 2^k protocol is not a performance decision alone. The README is explicit that these are different settings, and that GF(2^n) is a different thing again from modulo 2^n because every element has an inverse. A computation that needs integer arithmetic with 64-bit behaviour wants the mod 2^k column, and the protocols available there are a different set from the ones available in the prime column. ## Maintenance, releases and a custom licence The project is not archived and the last push was on 2026-10-07, so the codebase is being worked on. The release names describe what changed rather than just a version number, which is a good sign for a research framework. v0.4.1 was protocols with function-dependent preprocessing, v0.4.2 was expected communication cost in the compiler, and v0.4.3 was maintenance. That is a sequence of substantive additions followed by a consolidation, dated 2025-05-30, 2025-12-24 and 2026-07-06. The licence is the one to look at carefully. It is a custom licence that GitHub cannot classify, and the file is named License.txt rather than carrying a standard name, so this is not MIT and not Apache-2.0 by assumption. For a framework that other people build on and extend, the terms of that file are the terms your own distribution inherits, and they are worth reading before you build a product on it. The documentation is hosted on Read the Docs, with sections on frequently asked topics and on how to solve common issues, and there is a Gitter community linked from the README alongside the issue tracker and the mailing list archive. The CHANGELOG.md file in the repository is the place to look for what changed between the versions above, and the paper at eprint 2020/521 is the reference for the design if you want to understand why a protocol behaves the way it does. ## Conclusion MP-SPDZ fits a research group that needs to choose an MPC protocol on evidence rather than on reputation, a team writing a compiler or a protocol, and an engineer who wants to see what a malicious security model costs in communication and memory before committing to it. It does not fit a production system that needs a reviewed implementation, because the project says plainly that the software has not undergone the security review critical production code should have. Verify three things before you build on it: the licence in License.txt, which is a custom one rather than a standard permissive licence, the arithmetic you need, because a mod 2^k protocol and a mod prime protocol are not interchangeable and the matrix tells you which is which, and the expected communication cost for your program, which the compiler can report. ## FAQ ### What is MP-SPDZ used for? It is a framework for benchmarking secure multi-party computation protocols across security models such as honest and dishonest majority and semi-honest and malicious corruption, using secret sharing, homomorphic encryption and garbled circuits underneath. The stated primary aim is to run the same computation in various protocols so their performance can be compared. The README also says the software has not undergone the security review that critical production code should have. ### Which protocols does MP-SPDZ implement? The matrix in the README lists them by security model and arithmetic. Malicious with a dishonest majority covers MASCOT, LowGear and HighGear for modulo prime, SPDZ2k for mod 2^k, Tiny and Tinier for binary secret sharing and BMR for garbling. The honest majority rows cover Shamir, Rep3, PS, SY, Rep4, Brain, CCD, ATLAS, Astra and Trio, the covert row covers CowGear and ChaiGear, and the semi-honest dealer row offers the Dealer protocol. ### How do I run the MP-SPDZ tutorial? From a binary distribution, run Scripts/tldr.sh, write the input lines into Player-Data/Input-P0-0 and Player-Data/Input-P1-0, then run Scripts/compile-run.py -E mascot tutorial. From a source checkout, run make setup first and use the same inputs and the compile-run.py script. There is also a Docker route that builds an image with docker build --tag mpspdz:mascot-party --build-arg machine=mascot-party.x . and runs the tutorial in the container. ### How do I see the communication cost of a protocol in MP-SPDZ? The -E flag on compile-run.py and compile.py prints the expected communication cost, and it is the same flag shown in the tutorial command in the README. The compiler can also link you to the relevant papers with --papers, and the documentation has a systematic overview of the reading behind each protocol. ### What licence does MP-SPDZ use? A custom licence that GitHub cannot classify, in a file named License.txt at the root of the repository. It is not one of the standard permissive licences, so read that file before building on the framework or redistributing anything derived from it. ## Sources - [data61/MP-SPDZ on GitHub](https://github.com/data61/MP-SPDZ) - [Issues](https://github.com/data61/MP-SPDZ/issues) - [README](https://github.com/data61/MP-SPDZ/blob/master/README.md) - [Releases](https://github.com/data61/MP-SPDZ/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/data61-mp-spdz