{"id":13560810,"url":"https://github.com/data61/MP-SPDZ","last_synced_at":"2025-04-03T16:31:14.332Z","repository":{"id":37458208,"uuid":"152511277","full_name":"data61/MP-SPDZ","owner":"data61","description":"Versatile framework for multi-party computation","archived":false,"fork":true,"pushed_at":"2025-03-31T02:20:11.000Z","size":20197,"stargazers_count":998,"open_issues_count":14,"forks_count":291,"subscribers_count":19,"default_branch":"master","last_synced_at":"2025-03-31T03:24:20.057Z","etag":null,"topics":["confidential-computing","garbled-circuits","mpc","multi-party-computation","multiparty-computation","privacy-enhancing-technologies","secret-sharing","secure-computation","secure-multi-party-computation","secure-multiparty-computation","smpc","threshold-cryptography"],"latest_commit_sha":null,"homepage":"","language":"C++","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"bristolcrypto/SPDZ-2","license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/data61.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"License.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2018-10-11T01:16:16.000Z","updated_at":"2025-03-31T02:20:14.000Z","dependencies_parsed_at":"2023-09-26T17:44:37.083Z","dependency_job_id":null,"html_url":"https://github.com/data61/MP-SPDZ","commit_stats":null,"previous_names":[],"tags_count":40,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/data61%2FMP-SPDZ","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/data61%2FMP-SPDZ/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/data61%2FMP-SPDZ/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/data61%2FMP-SPDZ/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/data61","download_url":"https://codeload.github.com/data61/MP-SPDZ/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247036968,"owners_count":20873062,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["confidential-computing","garbled-circuits","mpc","multi-party-computation","multiparty-computation","privacy-enhancing-technologies","secret-sharing","secure-computation","secure-multi-party-computation","secure-multiparty-computation","smpc","threshold-cryptography"],"created_at":"2024-08-01T13:00:49.731Z","updated_at":"2025-04-03T16:31:14.325Z","avatar_url":"https://github.com/data61.png","language":"C++","readme":"# Multi-Protocol SPDZ [![Documentation Status](https://readthedocs.org/projects/mp-spdz/badge/?version=latest)](https://mp-spdz.readthedocs.io/en/latest/?badge=latest) [![Build Status](https://dev.azure.com/data61/MP-SPDZ/_apis/build/status/data61.MP-SPDZ?branchName=master)](https://dev.azure.com/data61/MP-SPDZ/_build/latest?definitionId=7\u0026branchName=master) [![Gitter](https://badges.gitter.im/MP-SPDZ/community.svg)](https://gitter.im/MP-SPDZ/community?utm_source=badge\u0026utm_medium=badge\u0026utm_campaign=pr-badge)\n\nThis is a software to benchmark various secure multi-party computation\n(MPC) protocols in a variety of security models such as honest and\ndishonest majority, semi-honest/passive and malicious/active\ncorruption. The underlying technologies span secret sharing,\nhomomorphic encryption, and garbled circuits.\n\n#### Contact\n\n[Filing an issue on GitHub](https://github.com/data61/MP-SPDZ/issues)\nis the preferred way of contacting\nus, but you can also write an email to mp-spdz@googlegroups.com\n([archive](https://groups.google.com/forum/#!forum/mp-spdz)). Before\nreporting a problem, please check against the list of [known\nissues and possible\nsolutions](https://mp-spdz.readthedocs.io/en/latest/troubleshooting.html).\n\n##### Filing Issues\n\nPlease file complete code examples because it's usually not possible\nto reproduce problems from incomplete code, and please include which\nprotocol you have used (if applicable) because there are considerable\ndifferences between the various protocols.\n\n#### Frequently Asked Questions\n\n[The documentation](https://mp-spdz.readthedocs.io/en/latest) contains\nsection on a number of [frequently asked\ntopics](https://mp-spdz.readthedocs.io/en/latest/troubleshooting.html)\nas well as information on how to solve common issues.\n\n#### TL;DR (Binary Distribution on Linux or Source Distribution on macOS)\n\nThis requires either a Linux distribution originally released 2018 or\nlater (glibc 2.18) or macOS High Sierra or later as well as Python 3\nand basic command-line utilities.\n\nDownload and unpack the\n[distribution](https://github.com/data61/MP-SPDZ/releases),\nthen execute the following from\nthe top folder:\n\n```\nScripts/tldr.sh\necho 1 2 3 4 \u003e Player-Data/Input-P0-0\necho 1 2 3 4 \u003e Player-Data/Input-P1-0\nScripts/compile-run.py -E mascot tutorial\n```\n\nThis runs [the tutorial](Programs/Source/tutorial.mpc) with two\nparties and malicious security.\n\n#### TL;DR (Source Distribution)\n\nOn Linux, this requires a working toolchain and [all\nrequirements](#requirements). On Ubuntu, the following might suffice:\n```\nsudo 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\n```\nOn MacOS, this requires [brew](https://brew.sh) to be installed,\nwhich will be used for all dependencies.\nIt will execute [the\ntutorial](Programs/Source/tutorial.mpc) with two parties and malicious\nsecurity.\n\n```\nmake setup\necho 1 2 3 4 \u003e Player-Data/Input-P0-0\necho 1 2 3 4 \u003e Player-Data/Input-P1-0\nScripts/compile-run.py mascot tutorial\n```\n\nOn strong enough hardware setups (several cores and GB of RAM), you\ncan speed up the last step by running `make -j8 mascot-party.x` beforehand.\n\n#### TL;DR (Docker)\nBuild a docker image for `mascot-party.x`:\n\n```\ndocker build --tag mpspdz:mascot-party --build-arg machine=mascot-party.x .\n```\n\nRun the [the tutorial](Programs/Source/tutorial.mpc):\n\n```\ndocker run --rm -it mpspdz:mascot-party ./Scripts/compile-run.py mascot tutorial\n```\n\nSee the [`Dockerfile`](./Dockerfile) for examples of how it can be used.\n\n#### Preface\n\nThe primary aim of this software is to run the same computation in\nvarious protocols in order to compare the performance. All protocols\nin the matrix below are fully implemented. However, this does not mean\nthat the software has undergone a security review as should be done\nwith critical production code.\n\n#### Protocols\n\nThe following table lists all protocols that are fully supported.\n\n| Security model | Mod prime / GF(2^n) | Mod 2^k | Bin. SS | Garbling |\n| --- | --- | --- | --- | --- |\n| Malicious, dishonest majority | [MASCOT / LowGear / HighGear](#secret-sharing) | [SPDZ2k](#secret-sharing) | [Tiny / Tinier](#secret-sharing) | [BMR](#bmr) |\n| Covert, dishonest majority | [CowGear / ChaiGear](#secret-sharing) | N/A | N/A | N/A |\n| Semi-honest, dishonest majority | [Semi / Hemi / Temi / Soho](#secret-sharing) | [Semi2k](#secret-sharing) | [SemiBin](#secret-sharing) | [Yao's GC](#yaos-garbled-circuits) / [BMR](#bmr) |\n| Malicious, honest majority | [Shamir / Rep3 / PS / SY](#honest-majority) | [Brain / Rep3 / PS / SY](#honest-majority) | [Rep3 / CCD / PS](#honest-majority) | [BMR](#bmr) |\n| Semi-honest, honest majority | [Shamir / ATLAS / Rep3](#honest-majority) | [Rep3](#honest-majority) | [Rep3 / CCD](#honest-majority) | [BMR](#bmr) |\n| Malicious, honest supermajority | [Rep4](#honest-majority) | [Rep4](#honest-majority) | [Rep4](#honest-majority) | N/A |\n| Semi-honest, dealer | [Dealer](#dealer-model) | [Dealer](#dealer-model) | [Dealer](#dealer-model) | N/A |\n\nModulo prime and modulo 2^k are the two settings that allow\ninteger-like computation. For k = 64, the latter corresponds to the\ncomputation available on the widely used 64-bit processors.  GF(2^n)\ndenotes Galois extension fields of order 2^n, which are different to\ncomputation modulo 2^n. In particular, every element has an inverse,\nwhich is not the case modulo 2^n. See [this\narticle](https://en.wikipedia.org/wiki/Finite_field) for an\nintroduction. Modulo prime and GF(2^n) are lumped together because the\nprotocols are very similar due to the mathematical properties.\n\nBin. SS stands for binary secret sharing, that is secret sharing\nmodulo two. In some settings, this requires specific protocols as some\nprotocols require the domain size to be larger than two. In other\nsettings, the protocol is the same mathematically speaking, but a\nspecific implementation allows for optimizations such as using the\ninherent parallelism of bit-wise operations on machine words.\n\nA security model specifies how many parties are \"allowed\" to misbehave\nin what sense. Malicious means that not following the protocol will at\nleast be detected while semi-honest means that even corrupted parties\nare assumed to follow the protocol.\nSee [this paper](https://eprint.iacr.org/2020/300) for an explanation\nof the various security models and a high-level introduction to\nmulti-party computation.\n\n##### Finding the most efficient protocol\n\nLower security requirements generally allow for more efficient\nprotocols. Within the same security model (line in the table above),\nthere are a few things to consider:\n\n- Computation domain: Arithmetic protocols (modulo prime or power of\n  two) are preferable for many applications because they offer integer\n  addition and multiplication at low cost. However, binary circuits\n  might be a better option if there is very little integer\n  computation. [See below](#finding-the-most-efficient-variant) to\n  find the most efficient mixed-circuit variant.  Furthermore, local\n  computation modulo a power of two is cheaper, but MP-SPDZ does not\n  offer this domain with homomorphic encryption.\n\n- Secret sharing vs garbled circuits: Computation using secret sharing\n  requires a number of communication rounds that grows depending on\n  the computation, which is not the case for garbled\n  circuits. However, the cost of integer computation as a binary\n  circuit often offset this. MP-SPDZ only offers garbled circuit\n  with binary computation.\n\n- Underlying technology for dishonest majority: While secret sharing\n  alone suffice honest-majority computation, dishonest majority\n  requires either homomorphic encryption (HE) or oblivious transfer\n  (OT). The two options offer a computation-communication trade-off:\n  While OT is easier to compute, HE requires less\n  communication. Furthermore, the latter requires a certain of\n  batching to be efficient, which makes OT preferable for smaller\n  tasks.\n\n- Malicious, honest-majority three-party computation: A number of\n  protocols are available for this setting, but SY/SPDZ-wise is the\n  most efficient one for a number of reasons: It requires the lowest\n  communication, and it is the only one offering constant-communication\n  dot products.\n\n- Fixed-point multiplication: Three- and four-party replicated secret\n  sharing as well semi-honest full-threshold protocols allow a special\n  probabilistic truncation protocol (see [Dalskov et\n  al.](https://eprint.iacr.org/2019/131) and [Dalskov et\n  al.](https://eprint.iacr.org/2020/1330)). You can activate it by\n  adding `program.use_trunc_pr = True` at the beginning of your\n  high-level program.\n\n- Larger number of parties: ATLAS scales better than the plain Shamir\n  protocol, and Temi scale better than Hemi or Semi.\n\n- Minor variants: Some command-line options change aspects of the\n  protocols such as:\n    - `--bucket-size`: In some malicious binary computation and\n      malicious edaBit generation, a smaller bucket size allows\n      preprocessing in smaller batches at a higher asymptotic cost.\n    - `--batch-size`: Preprocessing in smaller batches avoids generating\n      too much but larger batches save communication rounds.\n    - `--direct`: In protocols with any number of parties, direct communication\n      instead of star-shaped saves communication rounds at the expense\n      of a quadratic amount. This might be beneficial with a small\n      number of parties.\n    - `--bits-from-squares`: In some protocols computing modulo a prime\n      (Shamir, Rep3, SPDZ-wise), this switches from generating random\n      bits via XOR of parties' inputs to generation using the root of a\n      random square.\n\n#### Paper and Citation\n\nThe design of MP-SPDZ is described in [this\npaper](https://eprint.iacr.org/2020/521). If you use it for an\nacademic project, please cite:\n\n```\n@inproceedings{mp-spdz,\n    author = {Marcel Keller},\n    title = {{MP-SPDZ}: A Versatile Framework for Multi-Party Computation},\n    booktitle = {Proceedings of the 2020 ACM SIGSAC Conference on\n    Computer and Communications Security},\n    year = {2020},\n    doi = {10.1145/3372297.3417872},\n    url = {https://doi.org/10.1145/3372297.3417872},\n}\n```\n\n#### History\n\nThe software started out as an implementation of [the improved SPDZ\nprotocol](https://eprint.iacr.org/2012/642). The name SPDZ is derived\nfrom the authors of the [original\nprotocol](https://eprint.iacr.org/2011/535).\n\nThis repository combines the functionality previously published in the\nfollowing repositories:\n - https://github.com/bristolcrypto/SPDZ-2\n - https://github.com/mkskeller/SPDZ-BMR-ORAM\n - https://github.com/mkskeller/SPDZ-Yao\n\n#### Overview\n\nFor the actual computation, the software implements a virtual machine\nthat executes programs in a specific bytecode. Such code can be\ngenerated from high-level Python code using a compiler that optimizes\nthe computation with a particular focus on minimizing the number of\ncommunication rounds (for protocols based on secret sharing) or on\nAES-NI pipelining (for garbled circuits).\n\nThe software uses two different bytecode sets, one for\narithmetic circuits and one for boolean circuits. The high-level code\ndiffers between the two variants. Most computation functionality is\navailable in both, but binary circuits are lacking some input-output\nfunctionality.\n\nIn the section on computation we will explain how to compile a\nhigh-level program for the various computation domains and then how to\nrun it with different protocols.\n\nThe section on offline phases will explain how to benchmark the\noffline phases required for the SPDZ protocol. Running the online\nphase outputs the amount of offline material required, which allows to\ncompute the preprocessing time for a particular computation.\n\n#### Requirements\n\n - GCC 7 or later (tested with up to 14) or LLVM/clang 10 or later\n   (tested with up to 19). The default is to use clang because it performs\n   better.\n - For protocols using oblivious transfer, libOTe with [the necessary\n   patches](https://github.com/mkskeller/softspoken-implementation)\n   but without SimplestOT. The easiest way is to run `make libote`,\n   which will install it as needed in a subdirectory. libOTe requires\n   CMake of version at least 3.15, which is not available by default\n   on older systems such as Ubuntu 18.04. You can run `make cmake` to\n   install it locally.\n   libOTe also requires boost of version at least 1.75, which is not\n   available by default on relatively recent systems such as Ubuntu\n   22.04. You can install it locally by running `make boost`.\n - GMP library, compiled with C++ support (use flag `--enable-cxx`\n   when running configure). Tested against 6.2.1 as supplied by\n   Ubuntu.\n - libsodium library, tested against 1.0.18\n - OpenSSL, tested against 3.0.2\n - Boost.Asio with SSL support (`libboost-dev` on Ubuntu), tested against 1.81\n - Boost.Thread for BMR (`libboost-thread-dev` on Ubuntu), tested against 1.81\n - x86 or ARM 64-bit CPU (the latter tested with AWS Gravitron and\n   Apple Silicon)\n - Python 3.5 or later\n - NTL library for homomorphic encryption (optional; tested with NTL 11.5.1)\n - If using macOS, Sierra or later\n - Windows/VirtualBox: see [this\n   issue](https://github.com/data61/MP-SPDZ/issues/557) for a discussion\n\n#### Compilation\n\n1. Edit `CONFIG` or `CONFIG.mine` to your needs:\n\n    - On x86, the binaries are optimized for the CPU you are compiling\n      on. For all optimizations on x86, a CPU supporting AES-NI,\n      PCLMUL, AVX2, BMI2, ADX is required. This includes mainstream\n      processors released 2014 or later. If you intend to run on a\n      different CPU than compiling, you might need to change the `ARCH`\n      variable in `CONFIG` or `CONFIG.mine` to `-march=\u003ccpu\u003e`. See the\n      [GCC\n      documentation](https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html)\n      for the possible options.\n      To run on CPUs without AVX2 (CPUs from before 2014), you should\n      also add `AVX_OT = 0` to `CONFIG.mine`.\n    - For optimal results on Linux on ARM, add `ARCH = -march=armv8.2-a+crypto`\n      to `CONFIG.mine`. This enables the hardware support for AES. See the [GCC\n      documentation](https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html#AArch64-Options) on available options.\n    - To benchmark online-only protocols or Overdrive offline phases, add the following line at the top: `MY_CFLAGS = -DINSECURE`\n    - `PREP_DIR` should point to a local, unversioned directory to store preprocessing data (the default is `Player-Data` in the current directory).\n    - `SSL_DIR` should point to a local, unversioned directory to store ssl keys (the default is `Player-Data` in the current directory).\n    - For homomorphic encryption with GF(2^40), set `USE_NTL = 1`.\n    - To use KOS instead of SoftSpokenOT, add `USE_KOS = 1` and\n      `SECURE = -DINSECURE` to `CONFIG.mine`.\n    - On macOS, there have been issues with non-system compilers. Add\n      `CXX = /usr/bin/g++` to fix them.\n\n2. Run `make` to compile all the software (use the flag `-j` for faster\n   compilation using multiple threads). See below on how to compile specific\n   parts only. Remember to run `make clean` first after changing `CONFIG`\n   or `CONFIG.mine`.\n\n# Running Computation\n\nSee `Programs/Source/` for some example MPC programs, in particular\n`tutorial.mpc`. Furthermore, [Read the\nDocs](https://mp-spdz.readthedocs.io/en/latest/) hosts a more\ndetailed reference of all aspects of MP-SPDZ.\n\nThere are three ways of running computation:\n\n1. Separate compilation and execution. This is the default in the\n   further documentation. It allows to run the same program several\n   times while only compiling once, for example:\n\n   ```\n   ./compile.py \u003cprogram\u003e \u003cargument\u003e\n   Scripts/mascot.sh \u003cprogram\u003e-\u003cargument\u003e [\u003cruntime-arg\u003e...]\n   Scripts/mascot.sh \u003cprogram\u003e-\u003cargument\u003e [\u003cruntime-arg\u003e...]\n   ```\n\n2. One-command local execution. This compiles the program and the\n   virtual machine if necessary before executing it locally with the\n   given protocol. The name of the protocols correspond to the script\n   names below (without the `.sh`). Furthermore, some\n   protocol-specific optimization options are automatically used as\n   well as required options.\n\n   ```\n   Scripts/compile-run.py -E mascot \u003cprogram\u003e \u003cargument\u003e -- [\u003cruntime-arg\u003e...]\n   ```\n\n3. One-command remote execution. This compiles the program and the\n   virtual machine if necessary before uploading them together with\n   all necessary input and certificate files via SSH.\n\n   ```\n   Scripts/compile-run.py -H HOSTS -E mascot \u003cprogram\u003e \u003cargument\u003e -- [\u003cruntime-arg\u003e...]\n   ```\n\n   `HOSTS` has to be a text file in the following format:\n\n   ```\n   [\u003cuser\u003e@]\u003chost0\u003e[/\u003cpath\u003e]\n   [\u003cuser\u003e@]\u003chost1\u003e[/\u003cpath\u003e]\n   ...\n   ```\n\n   If \u003cpath\u003e does not start with `/` (only one `/` after the\n   hostname), the path will be relative to the home directory of the\n   user. Otherwise (`//` after the hostname it will be relative to the\n   root directory.\n\n   It is assumed that the SSH login is possible without password.\n\n   Adding the compiler option `-t` (`--tidy_output`) groups the output prints by\n   party; however, it delays the outputs until the execution is finished.\n\nEven with the integrated execution it is important to keep in mind\nthat there are two different phases, the compilation and the run-time\nphase. Any secret data is only available in the second phase, when the\nPython compilation has concluded. Therefore, the types like `sint` and\n`sfix` are mere placeholders for data to be used later, and they don't\ncontain any shares. See also [the\ndocumentation](https://mp-spdz.readthedocs.io/en/latest/compilation.html#compilation-vs-run-time)\nfor what this means when using Python data structures and Python\nlanguage features.\n\n\n### Compiling high-level programs\n\nThere are three computation domains, and the high-level programs have\nto be compiled accordingly.\n\n#### Arithmetic modulo a prime\n\n```./compile.py [-F \u003cinteger bit length\u003e] [-P \u003cprime\u003e] \u003cprogram\u003e```\n\nThe integer bit length defaults to 64, and the prime defaults to none\ngiven. If a prime is given, it has to be at least two bits longer than\nthe integer length. Note that `-P` is optional, and it involves\nalgorithms that are more expensive while allowing for a wider range of\ninteger lengths.\n\nThe command-line options primarily affects non-linear computation such\nas comparisons. See the [documentation on non-linear\ncomputation](https://mp-spdz.readthedocs.io/en/latest/non-linear.html)\nfor more details and pointers to relevant papers.\n\nNote that in this context integers do not wrap around according to the\ninteger bit length but the length is used for non-linear\ncomputations such as comparison.\nOverflow in secret integers might have security implications if no\nconcrete prime is given.\n\nThe parameters given together with the computation mandate some\nrestriction on the prime modulus, either an exact value or a minimum\nlength. The latter is roughly the integer length plus 40 (default\nsecurity parameter). The restrictions are communicated to the virtual\nmachines, which will use an appropriate prime if they have been\ncompiled accordingly. By default, they are compiled for prime bit\nlengths up to 256. For larger primes, you will have to compile with\n`MOD = -DGFP_MOD_SZ=\u003cnumber of limbs\u003e` in `CONFIG.mine` where the\nnumber of limbs is the the prime length divided by 64 rounded up.\n\nThe precision for fixed- and floating-point computation are not\naffected by the integer bit length but can be set in the code\ndirectly. For fixed-point computation this is done via\n`sfix.set_precision()`.\n\n#### Arithmetic modulo 2^k\n\n```./compile.py -R \u003cinteger bit length\u003e \u003cprogram\u003e```\n\nThe length is communicated to the virtual machines and automatically\nused if supported. By default, they support bit lengths 64, 72, and\n128 (the latter except for SPDZ2k). If another length is required, use\n`MOD = -DRING_SIZE=\u003cbit length\u003e` in `CONFIG.mine`.\n\n#### Binary circuits\n\n```./compile.py -B \u003cinteger bit length\u003e \u003cprogram\u003e```\n\nThe integer length can be any number up to a maximum depending on the\nprotocol. All protocols support at least 64-bit integers.\n\nFixed-point numbers (`sfix`) always use 16/16-bit precision by default in\nbinary circuits. This can be changed with `sfix.set_precision`. See\n[the tutorial](Programs/Source/tutorial.mpc).\n\nIf you would like to use integers of various precisions, you can use\n`sbitint.get_type(n)` to get a type for `n`-bit arithmetic.\n\n#### Mixed circuits\n\nMP-SPDZ allows to mix computation between arithmetic and binary\nsecret sharing in the same security model. In the compiler, this is\nused to switch from arithmetic to binary computation for certain\nnon-linear functions such as\ncomparison, bit decomposition, truncation, and modulo power of two,\nwhich are use for fixed- and floating-point operations. There are\nseveral ways of achieving this as described below.\n\n##### Classic daBits\n\nYou can activate this by adding `-X` when compiling arithmetic\ncircuits, that is\n```./compile.py -X [-F \u003cinteger bit length\u003e] \u003cprogram\u003e```\nfor computation modulo a prime and\n```./compile.py -X -R \u003cinteger bit length\u003e \u003cprogram\u003e```\nfor computation modulo 2^k.\n\nInternally, this uses daBits described by [Rotaru and\nWood](https://eprint.iacr.org/2019/207), that is secret random bits\nshared in different domains. Some security models allow direct\nconversion of random bits from arithmetic to binary while others\nrequire inputs from several parties followed by computing XOR and\nchecking for malicious security as described by Rotaru and Wood in\nSection 4.1.\n\n##### Extended daBits\n\nExtended daBits were introduced by [Escudero et\nal.](https://eprint.iacr.org/2020/338). You can activate them by using\n`-Y` instead of `-X`. Note that this also activates classic daBits\nwhen useful.\n\n##### Local share conversion\n\nThis technique has been used by [Mohassel and\nRindal](https://eprint.iacr.org/2018/403) as well as [Araki et\nal.](https://eprint.iacr.org/2018/762) for three parties and [Demmler\net al.](https://encrypto.de/papers/DSZ15.pdf) for two parties.\nIt involves locally\nconverting an arithmetic share to a set of binary shares, from which the\nbinary equivalent to the arithmetic share is reconstructed using a\nbinary adder. This requires additive secret sharing over a ring\nwithout any MACs. You can activate it by using `-Z \u003cn\u003e` with the\ncompiler where `n` is the number of parties for the standard variant\nand 2 for the special\nvariant by Mohassel and Rindal (available in Rep3 only).\n\n##### Finding the most efficient variant\n\nWhere available, local share conversion is likely the most efficient\nvariant. Otherwise, edaBits likely offer an asymptotic benefit. When\nusing edaBits with malicious protocols, there is a trade-off between\ncost per item and batch size. The lowest cost per item requires large\nbatches of edaBits (more than one million at once), which is only\nworthwhile for accordingly large computation. This setting can be\nselected by running the virtual machine with `-B 3`. For smaller\ncomputation, try `-B 4` or `-B 5`, which set the batch size to ~10,000\nand ~1,000, respectively, at a higher asymptotic cost. `-B 4` is the\ndefault.\n\n#### Bristol Fashion circuits\n\nBristol Fashion is the name of a description format of binary circuits\nused by\n[SCALE-MAMBA](https://github.com/KULeuven-COSIC/SCALE-MAMBA). You can\naccess such circuits from the high-level language if they are present\nin `Programs/Circuits`. To run the AES-128 circuit provided with\nSCALE-MAMBA, you can run the following:\n\n```\nmake Programs/Circuits\n./compile.py aes_circuit\nScripts/semi.sh aes_circuit\n```\n\nThis downloads the circuit, compiles it to MP-SPDZ bytecode, and runs\nit as semi-honest two-party computation 1000 times in parallel. It\nshould then output the AES test vector\n`0x3ad77bb40d7a3660a89ecaf32466ef97`. You can run it with any other\nprotocol as well.\n\nSee the\n[documentation](https://mp-spdz.readthedocs.io/en/latest/Compiler.html#module-Compiler.circuit)\nfor further examples.\n\n#### Compiling programs directly in Python\n\nYou may prefer to not have an entirely static `.mpc` file to compile, and may want to compile based on dynamic inputs. For example, you may want to be able to compile with different sizes of input data without making a code change to the `.mpc` file. To handle this, the compiler an also be directly imported, and a function can be compiled with the following interface:\n\n```python\n# hello_world.mpc\nfrom Compiler.library import print_ln\nfrom Compiler.compilerLib import Compiler\n\ncompiler = Compiler()\n\n@compiler.register_function('helloworld')\ndef hello_world():\n    print_ln('hello world')\n\nif __name__ == \"__main__\":\n    compiler.compile_func()\n```\n\nYou could then run this with the same args as used with `compile.py`:\n\n```bash\npython hello_world.mpc \u003ccompile args\u003e\n```\n\nThis is particularly useful if want to add new command line arguments specifically for your `.mpc` file. See [test_args.mpc](Programs/Source/test_args.mpc) for more details on this use case.\n\nNote that when using this approach, all objects provided in the high level interface (e.g. sint, print_ln) need to be imported, because the `.mpc` file is interpreted directly by Python (instead of being read by `compile.py`.)\n\nFurthermore, this only covers compilation, so you will need to run execution separately, for example:\n```\nScripts/mascot.sh hello_world\n```\n\nAlso note that programs in the above form are not compatible with `compile.py` and `compile-run.py`.\n\n#### Compiling and running programs from external directories\n\nPrograms can also be edited, compiled and run from any directory with\nthe above basic structure. So for a source file in\n`./Programs/Source/`, all MP-SPDZ scripts must be run from `./`. Any\nsetup scripts such as `setup-ssl.sh` script must also be run from `./`\nto create the relevant data. For example:\n\n```\nMP-SPDZ$ cd ../\n$ mkdir myprogs\n$ cd myprogs\n$ mkdir -p Programs/Source\n$ vi Programs/Source/test.mpc\n$ ../MP-SPDZ/compile.py test.mpc\n$ ls Programs/\nBytecode  Public-Input  Schedules  Source\n$ ../MP-SPDZ/Scripts/setup-ssl.sh\n$ ls\nPlayer-Data Programs\n$ ../MP-SPDZ/Scripts/rep-field.sh test\n```\n\n### TensorFlow inference\n\n**Note: All networks mentioned below are now supported by the\n[PyTorch\ninterface](https://mp-spdz.readthedocs.io/en/latest/machine-learning.html#loading-pre-trained-models),\nwhich is better integrated and thus easier to use. This section is\nmerely kept to document the approach used for [an earlier\npaper](https://eprint.iacr.org/2019/131), but it is recommended to use\nthe PyTorch interface.**\n\nMP-SPDZ supports inference with selected TensorFlow graphs, in\nparticular DenseNet, ResNet, and SqueezeNet as used in\n[CrypTFlow](https://github.com/mpc-msri/EzPC). For example, you can\nrun SqueezeNet inference for ImageNet as follows:\n\n```\ngit clone https://github.com/mkskeller/EzPC\ncd EzPC/Athos/Networks/SqueezeNetImgNet\naxel -a -n 5 -c --output ./PreTrainedModel https://github.com/avoroshilov/tf-squeezenet/raw/master/sqz_full.mat\npip3 install numpy scipy pillow\u003e=9.1 tensorflow\npython3 squeezenet_main.py --in ./SampleImages/n02109961_36.JPEG --saveTFMetadata True\npython3 squeezenet_main.py --in ./SampleImages/n02109961_36.JPEG --scalingFac 12 --saveImgAndWtData True\ncd ../../../..\ncp EzPC/Athos/Networks/SqueezeNetImgNet/SqNetImgNet_img_input.inp Player-Data/Input-Binary-P0-0\n./compile.py -R 64 tf EzPC/Athos/Networks/SqueezeNetImgNet/graphDef.bin 1 trunc_pr split\nScripts/ring.sh tf-EzPC_Athos_Networks_SqueezeNetImgNet_graphDef.bin-1-trunc_pr-split\n```\n\nThis requires TensorFlow and the axel command-line utility to be\ninstalled. It runs inference with\nthree-party semi-honest computation, similar to CrypTFlow's\nPorthos. Replace 1 by the desired number of thread in the last two\nlines. If you run with some other protocols, you will need to remove\n`trunc_pr` and/or `split`. Also note that you will need to use a\nCrypTFlow repository that includes the patches in\nhttps://github.com/mkskeller/EzPC.\n\n[The reference](https://mp-spdz.readthedocs.io/en/latest/Compiler.html#module-Compiler.ml)\ncontains further documentation on available layers.\n\n### Emulation\n\nFor arithmetic circuits modulo a power of two and binary circuits, you\ncan emulate the computation as follows:\n\n``` ./emulate.x \u003cprogram\u003e ```\n\nThis runs the compiled bytecode in cleartext computation, that is,\n*no* multi-party computation is performed.\n\n## Dishonest majority\n\nSome full implementations require oblivious transfer, which is\nimplemented as OT extension based on\nhttps://github.com/mkskeller/SimpleOT or\nhttps://github.com/mkskeller/SimplestOT_C, depending on whether AVX is\navailable.\n\n### Secret sharing\n\nThe following table shows all programs for dishonest-majority computation using secret sharing:\n\n| Program | Protocol | Domain | Security | Script |\n| --- | --- | --- | --- | --- |\n| `mascot-party.x` | [MASCOT](https://eprint.iacr.org/2016/505) | Mod prime | Malicious | `mascot.sh` |\n| `mama-party.x` | MASCOT* | Mod prime | Malicious | `mama.sh` |\n| `spdz2k-party.x` | [SPDZ2k](https://eprint.iacr.org/2018/482) | Mod 2^k | Malicious | `spdz2k.sh` |\n| `semi-party.x` | OT-based | Mod prime | Semi-honest | `semi.sh` |\n| `semi2k-party.x` | OT-based | Mod 2^k | Semi-honest | `semi2k.sh` |\n| `lowgear-party.x` | [LowGear](https://eprint.iacr.org/2017/1230) | Mod prime | Malicious | `lowgear.sh` |\n| `highgear-party.x` | [HighGear](https://eprint.iacr.org/2017/1230) | Mod prime | Malicious | `highgear.sh` |\n| `cowgear-party.x` | Adapted [LowGear](https://eprint.iacr.org/2017/1230) | Mod prime | Covert | `cowgear.sh` |\n| `chaigear-party.x` | Adapted [HighGear](https://eprint.iacr.org/2017/1230) | Mod prime | Covert | `chaigear.sh` |\n| `hemi-party.x` | Semi-homomorphic encryption | Mod prime | Semi-honest | `hemi.sh` |\n| `temi-party.x` | Adapted [CDN01](https://eprint.iacr.org/2022/933) | Mod prime | Semi-honest | `temi.sh` |\n| `soho-party.x` | Somewhat homomorphic encryption | Mod prime | Semi-honest | `soho.sh` |\n| `semi-bin-party.x` | OT-based | Binary | Semi-honest | `semi-bin.sh` |\n| `tiny-party.x` | Adapted SPDZ2k | Binary | Malicious | `tiny.sh` |\n| `tinier-party.x` | [FKOS15](https://eprint.iacr.org/2015/901) | Binary | Malicious | `tinier.sh` |\n\nMama denotes MASCOT with several MACs to increase the security\nparameter to a multiple of the prime length.\n\nSemi and Semi2k denote the result of stripping MASCOT/SPDZ2k of all\nsteps required for malicious security, namely amplifying, sacrificing,\nMAC generation, and OT correlation checks. What remains is the\ngeneration of additively shared Beaver triples using OT.\n\nSimilarly, SemiBin denotes a protocol that generates bit-wise\nmultiplication triples using OT without any element of malicious\nsecurity.\n\nTiny denotes the adaption of SPDZ2k to the binary setting. In\nparticular, the SPDZ2k sacrifice does not work for bits, so we replace\nit by cut-and-choose according to [Furukawa et\nal.](https://eprint.iacr.org/2016/944)\nTinier on the other hand denotes the protocol by [Frederiksen et\nal.](https://eprint.iacr.org/2015/901) also using the cut-and-choose\nsacrifice by Furukawa et al.\n\nThe virtual machines for LowGear and HighGear run a key generation\nsimilar to the one by [Rotaru et\nal.](https://eprint.iacr.org/2019/1300). The main difference is using\ndaBits to generate maBits. CowGear and ChaiGear denote covertly\nsecure versions of LowGear and HighGear. In all relevant programs,\noption `-T` activates [TopGear](https://eprint.iacr.org/2019/035)\nzero-knowledge proofs in both.\n\nHemi and Soho denote the stripped version of LowGear and\nHighGear, respectively, for semi-honest\nsecurity similar to Semi, that is, generating additively shared Beaver\ntriples using semi-homomorphic encryption.\nTemi in turn denotes the adaption of\n[Cramer et al.](https://eprint.iacr.org/2000/055) to LWE-based\nsemi-homomorphic encryption as described in Appendix B of [this\nwork](https://eprint.iacr.org/2022/933).\nBoth Hemi and Temi use the diagonal packing by [Halevi and\nShoup](https://eprint.iacr.org/2014/106) for matrix multiplication.\n\nWe will use MASCOT to demonstrate the use, but the other protocols\nwork similarly.\n\nFirst compile the virtual machine:\n\n`make -j8 mascot-party.x`\n\nand a high-level program, for example the tutorial (use `-R 64` for\nSPDZ2k and Semi2k and `-B \u003cprecision\u003e` for SemiBin):\n\n`./compile.py -F 64 tutorial`\n\nTo run the tutorial with two parties on one machine, run:\n\n`./mascot-party.x -N 2 -I -p 0 tutorial`\n\n`./mascot-party.x -N 2 -I -p 1 tutorial` (in a separate terminal)\n\nUsing `-I` activates interactive mode, which means that inputs are\nsolicited from standard input, and outputs are given to any\nparty. Omitting `-I` leads to inputs being read from\n`Player-Data/Input-P\u003cparty number\u003e-0` in text format.\n\nOr, you can use a script to do run two parties in non-interactive mode\nautomatically:\n\n`Scripts/mascot.sh tutorial`\n\nTo run a program on two different machines, `mascot-party.x`\nneeds to be passed the machine where the first party is running,\ne.g. if this machine is name `diffie` on the local network:\n\n`./mascot-party.x -N 2 -h diffie 0 tutorial`\n\n`./mascot-party.x -N 2 -h diffie 1 tutorial`\n\nThe software uses TCP ports around 5000 by default, use the `-pn`\nargument to change that.\n\n\n### Yao's garbled circuits\n\nWe use half-gate garbling as described by [Zahur et\nal.](https://eprint.iacr.org/2014/756.pdf) and [Guo et\nal.](https://eprint.iacr.org/2019/1168.pdf). Alternatively, you can\nactivate the implementation optimized by [Bellare et\nal.](https://eprint.iacr.org/2013/426) by adding `MY_CFLAGS +=\n-DFULL_GATES` to `CONFIG.mine`.\n\nCompile the virtual machine:\n\n`make -j 8 yao`\n\nand the high-level program:\n\n`./compile.py -G -B \u003cinteger bit length\u003e \u003cprogram\u003e`\n\nThen run as follows:\n\n  - Garbler: ```./yao-party.x [-I] -p 0 \u003cprogram\u003e```\n  - Evaluator: ```./yao-party.x [-I] -p 1 -h \u003cgarbler host\u003e \u003cprogram\u003e```\n\nWhen running locally, you can omit the host argument. As above, `-I`\nactivates interactive input, otherwise inputs are read from\n`Player-Data/Input-P\u003cplayerno\u003e-0`.\n\nBy default, the circuit is garbled in chunks that are evaluated\nwhenever received.You can activate garbling all at once by adding\n`-O` to the command line on both sides.\n\n## Honest majority\n\nThe following table shows all programs for honest-majority computation:\n\n| Program | Sharing | Domain | Malicious | \\# parties | Script |\n| --- | --- | --- | --- | --- | --- |\n| `replicated-ring-party.x` | Replicated | Mod 2^k | N | 3 | `ring.sh` |\n| `brain-party.x` | Replicated | Mod 2^k | Y | 3 | `brain.sh` |\n| `ps-rep-ring-party.x` | Replicated | Mod 2^k | Y | 3 | `ps-rep-ring.sh` |\n| `malicious-rep-ring-party.x` | Replicated | Mod 2^k | Y | 3 | `mal-rep-ring.sh` |\n| `sy-rep-ring-party.x` | SPDZ-wise replicated | Mod 2^k | Y | 3 | `sy-rep-ring.sh` |\n| `rep4-ring-party.x` | Replicated | Mod 2^k | Y | 4 | `rep4-ring.sh` |\n| `replicated-bin-party.x` | Replicated | Binary | N | 3 | `replicated.sh` |\n| `malicious-rep-bin-party.x` | Replicated | Binary | Y | 3 | `mal-rep-bin.sh` |\n| `ps-rep-bin-party.x` | Replicated | Binary | Y | 3 | `ps-rep-bin.sh` |\n| `replicated-field-party.x` | Replicated | Mod prime | N | 3 | `rep-field.sh` |\n| `ps-rep-field-party.x` | Replicated | Mod prime | Y | 3 | `ps-rep-field.sh` |\n| `sy-rep-field-party.x` | SPDZ-wise replicated | Mod prime | Y | 3 | `sy-rep-field.sh` |\n| `malicious-rep-field-party.x` | Replicated | Mod prime | Y | 3 | `mal-rep-field.sh` |\n| `atlas-party.x` | [ATLAS](https://eprint.iacr.org/2021/833) | Mod prime | N | 3 or more | `atlas.sh` |\n| `shamir-party.x` | Shamir | Mod prime | N | 3 or more | `shamir.sh` |\n| `malicious-shamir-party.x` | Shamir | Mod prime | Y | 3 or more | `mal-shamir.sh` |\n| `sy-shamir-party.x` | SPDZ-wise Shamir | Mod prime | Y | 3 or more | `sy-shamir.sh` |\n| `ccd-party.x` | CCD/Shamir | Binary | N | 3 or more | `ccd.sh` |\n| `malicious-cdd-party.x` | CCD/Shamir | Binary | Y | 3 or more | `mal-ccd.sh` |\n\nWe use the \"generate random triple optimistically/sacrifice/Beaver\"\nmethodology described by [Lindell and\nNof](https://eprint.iacr.org/2017/816) to achieve malicious\nsecurity with plain arithmetic replicated secret sharing,\nexcept for the \"PS\" (post-sacrifice) protocols where the\nactual multiplication is executed optimistically and checked later as\nalso described by Lindell and Nof.\nThe implementations used by `brain-party.x`,\n`malicious-rep-ring-party.x -S`, `malicious-rep-ring-party.x`,\nand `ps-rep-ring-party.x` correspond to the protocols called DOS18\npreprocessing (single), ABF+17 preprocessing, CDE+18 preprocessing,\nand postprocessing, respectively,\nby [Eerikson et al.](https://eprint.iacr.org/2019/164)\nWe use resharing by [Cramer et\nal.](https://eprint.iacr.org/2000/037) for Shamir's secret sharing and\nthe optimized approach by [Araki et\nal.](https://eprint.iacr.org/2016/768) for replicated secret sharing.\nThe CCD protocols are named after the [historic\npaper](https://doi.org/10.1145/62212.62214) by Chaum, Crépeau, and\nDamgård, which introduced binary computation using Shamir secret\nsharing over extension fields of characteristic two.\nSY/SPDZ-wise refers to the line of work started by [Chida et\nal.](https://eprint.iacr.org/2018/570) for computation modulo a prime\nand furthered by [Abspoel et al.](https://eprint.iacr.org/2019/1298)\nfor computation modulo a power of two. It involves sharing both a\nsecret value and information-theoretic tag similar to SPDZ but not\nwith additive secret sharing, hence the name.\nRep4 refers to the four-party protocol by [Dalskov et\nal.](https://eprint.iacr.org/2020/1330)\n`malicious-rep-bin-party.x` is based on cut-and-choose triple\ngeneration by [Furukawa et al.](https://eprint.iacr.org/2016/944) but\nusing Beaver multiplication instead of their post-sacrifice\napproach. `ps-rep-bin-party.x` is based on the post-sacrifice approach\nby [Araki et\nal.](https://www.ieee-security.org/TC/SP2017/papers/96.pdf) but\nwithout using their cache optimization.\n\nAll protocols in this section require encrypted channels because the\ninformation received by the honest majority suffices the reconstruct\nall secrets. Therefore, an eavesdropper on the network could learn all\ninformation.\n\nMP-SPDZ uses OpenSSL for secure channels. You can generate the\nnecessary certificates and keys as follows:\n\n`Scripts/setup-ssl.sh [\u003cnumber of parties\u003e \u003cssl_dir\u003e]`\n\nThe programs expect the keys and certificates to be in\n`SSL_DIR/P\u003ci\u003e.key` and `SSL_DIR/P\u003ci\u003e.pem`, respectively, and\nthe certificates to have the common name `P\u003ci\u003e` for player\n`\u003ci\u003e`. Furthermore, the relevant root certificates have to be in\n`SSL_DIR` such that OpenSSL can find them (run `c_rehash\n\u003cssl_dir\u003e`). The script above takes care of all this by generating\nself-signed certificates. Therefore, if you are running the programs\non different hosts you will need to copy the certificate files.\nNote that `\u003cssl_dir\u003e` must match `SSL_DIR` set in `CONFIG` or `CONFIG.mine`.\nJust like `SSL_DIR`, `\u003cssl_dir\u003e` defaults to `Player-Data`.\n\nIn the following, we will walk through running the tutorial modulo\n2^k with three parties. The other programs work similarly.\n\nFirst, compile the virtual machine:\n\n`make -j 8 replicated-ring-party.x`\n\nIn order to compile a high-level program, use `./compile.py -R 64`:\n\n`./compile.py -R 64 tutorial`\n\nIf using another computation domain, use `-F` or `-B` as described in\n[the relevant section above](#compiling-high-level-programs).\n\nFinally, run the three parties as follows:\n\n`./replicated-ring-party.x -I 0 tutorial`\n\n`./replicated-ring-party.x -I 1 tutorial` (in a separate terminal)\n\n`./replicated-ring-party.x -I 2 tutorial` (in a separate terminal)\n\nor\n\n`Scripts/ring.sh tutorial`\n\nThe `-I` argument enables interactive inputs, and in the tutorial party 0 and 1\nwill be asked to provide three numbers. Otherwise, and when using the\nscript, the inputs are read from `Player-Data/Input-P\u003cplayerno\u003e-0`.\n\nWhen using programs based on Shamir's secret sharing, you can specify\nthe number of parties with `-N` and the maximum number of corrupted\nparties with `-T`. The latter can be at most half the number of\nparties.\n\n## Dealer model\n\nThis security model defines a special party that generates correlated\nrandomness such as multiplication triples, which is then used by all\nother parties. MP-SPDZ implements the canonical protocol where the\nother parties run the online phase of the semi-honest protocol in\nSemi(2k/Bin) and the dealer provides all preprocessing. The security\nassumption is that dealer doesn't collude with any other party, but\nall but one of the other parties are allowed to collude. In our\nimplementation, the dealer is the party with the highest number, so\nwith three parties overall, Party 0 and 1 run the online phase.\n\n| Program | Sharing | Domain | Malicious | \\# parties | Script |\n| --- | --- | --- | --- | --- | --- |\n| `dealer-ring-party.x` | Additive | Mod 2^k | N | 3+ | `dealer-ring.sh` |\n\n## BMR\n\nBMR (Beaver-Micali-Rogaway) is a method of generating a garbled circuit\nusing another secure computation protocol. We have implemented BMR\nbased on all available implementations using GF(2^128) because the nature\nof this field particularly suits the Free-XOR optimization for garbled\ncircuits. Our implementation is based on the [SPDZ-BMR-ORAM\nconstruction](https://eprint.iacr.org/2017/981). The following table\nlists the available schemes.\n\n| Program | Protocol | Dishonest Maj. | Malicious | \\# parties | Script |\n| --- | --- | --- | --- | --- | --- |\n| `real-bmr-party.x` | MASCOT | Y | Y | 2 or more | `real-bmr.sh` |\n| `semi-bmr-party.x` | Semi | Y | N | 2 or more | `semi-bmr.sh` |\n| `shamir-bmr-party.x` | Shamir | N | N | 3 or more | `shamir-bmr.sh` |\n| `mal-shamir-bmr-party.x` | Shamir | N | Y | 3 or more | `mal-shamir-bmr.sh` |\n| `rep-bmr-party.x` | Replicated | N | N | 3 | `rep-bmr.sh` |\n| `mal-rep-bmr-party.x` | Replicated | N | Y | 3 | `mal-rep-bmr.sh` |\n\nIn the following, we will walk through running the tutorial with BMR\nbased on MASCOT and two parties. The other programs work similarly.\n\nFirst, compile the virtual machine. In order to run with more than\nthree parties, change the definition of `MAX_N_PARTIES` in\n`BMR/config.h` accordingly.\n\n`make -j 8 real-bmr-party.x`\n\nIn order to compile a high-level program, use `./compile.py -B`:\n\n`./compile.py -G -B 32 tutorial`\n\nFinally, run the two parties as follows:\n\n`./real-bmr-party.x -I 0 tutorial`\n\n`./real-bmr-party.x -I 1 tutorial` (in a separate terminal)\n\nor\n\n`Scripts/real-bmr.sh tutorial`\n\nThe `-I` enable interactive inputs, and in the tutorial party 0 and 1\nwill be asked to provide three numbers. Otherwise, and when using the\nscript, the inputs are read from `Player-Data/Input-P\u003cplayerno\u003e-0`.\n\n## Online-only benchmarking\n\nIn this section we show how to benchmark purely the data-dependent\n(often called online) phase of some protocols. This requires to\ngenerate the output of a previous phase. There are two options to do\nthat:\n1. For select protocols, you can run [preprocessing as\n   required](#preprocessing-as-required).\n2. You can run insecure preprocessing. For this, you will have to\n   (re)compile the software after adding `MY_CFLAGS = -DINSECURE` to\n   `CONFIG.mine` in order to run this insecure generation.\n   Make sure to run `make clean` before recompiling any binaries.\n   Then, you need to run `make Fake-Offline.x \u003cprotocol\u003e-party.x`.\n\nNote that you can as well run the full protocol with option `-v` to\nsee the cost split by preprocessing and online phase.\n\n### SPDZ\n\nThe SPDZ protocol uses preprocessing, that is, in a first (sometimes\ncalled offline) phase correlated randomness is generated independent\nof the actual inputs of the computation. Only the second (\"online\")\nphase combines this randomness with the actual inputs in order to\nproduce the desired results. The preprocessed data can only be used\nonce, thus more computation requires more preprocessing. MASCOT and\nOverdrive are the names for two alternative preprocessing phases to go\nwith the SPDZ online phase.\n\nAll programs required in this section can be compiled with the target `online`:\n\n`make -j 8 online`\n\n#### To setup for benchmarking the online phase\n\nThis requires the INSECURE flag to be set before compilation as explained above. For a secure offline phase, see the section on SPDZ-2 below.\n\nRun the command below. **If you haven't added `MY_CFLAGS = -DINSECURE` to `CONFIG.mine` before compiling, it will fail.**\n\n`Scripts/setup-online.sh`\n\nThis sets up parameters for the online phase for 2 parties with a 128-bit prime field and 128-bit binary field, and creates fake offline data (multiplication triples etc.) for these parameters.\n\nParameters can be customised by running\n\n`Scripts/setup-online.sh \u003cnparties\u003e \u003cnbitsp\u003e [\u003cnbits2\u003e]`\n\n\n#### To compile a program\n\nTo compile for example the program in `./Programs/Source/tutorial.mpc`, run:\n\n`./compile.py tutorial`\n\nThis creates the bytecode and schedule files in Programs/Bytecode/ and Programs/Schedules/\n\n#### To run a program\n\nTo run the above program with two parties on one machine, run:\n\n`./mascot-party.x -F -N 2 0 tutorial`\n\n`./mascot-party.x -F -N 2 1 tutorial` (in a separate terminal)\n\nOr, you can use a script to do the above automatically:\n\n`Scripts/mascot.sh -F tutorial`\n\nMASCOT is one of the protocols that use SPDZ for the online phase, and\n`-F` causes the programs to read preprocessing material from files.\n\nTo run a program on two different machines, firstly the preprocessing\ndata must be copied across to the second machine (or shared using\nsshfs), and secondly, `mascot-party.x` needs to be passed the machine\nwhere the first party is running. E.g., if this machine is named\n`diffie` on the local network:\n\n`./mascot-party.x -F -N 2 -h diffie 0 test_all`\n\n`./mascot-party.x -F -N 2 -h diffie 1 test_all`\n\nThe software uses TCP ports around 5000 by default, use the `-pn`\nargument to change that.\n\n### SPDZ2k\n\nCreating fake offline data for SPDZ2k requires to call\n`Fake-Offline.x` directly instead of via `setup-online.sh`:\n\n`./Fake-Offline.x \u003cnparties\u003e -Z \u003cbit length k for SPDZ2k\u003e -S \u003csecurity parameter\u003e`\n\nYou will need to run `spdz2k-party.x -F` in order to use the data from storage.\n\n### Other protocols\n\nPreprocessing data for the default parameters of most other protocols\ncan be produced as follows:\n\n`./Fake-Offline.x \u003cnparties\u003e -e \u003cedaBit length,...\u003e`\n\nThe `-e` command-line parameters accepts a list of integers separated\nby commas.\n\nYou can then run the protocol with argument `-F`. Note that when\nrunning on several hosts, you will need to distribute the data in\n`Player-Data`. The preprocessing files contain `-P\u003cparty number\u003e`\nindicating which party will access it.\n\n### BMR\n\nThis part has been developed to benchmark ORAM for the [Eurocrypt 2018\npaper](https://eprint.iacr.org/2017/981) by Marcel Keller and Avishay\nYanay. It only allows to benchmark the data-dependent phase. The\ndata-independent and function-independent phases are emulated\ninsecurely.\n\nBy default, the implementations is optimized for two parties. You can\nchange this by defining `N_PARTIES` accordingly in `BMR/config.h`. If\nyou entirely delete the definition, it will be able to run for any\nnumber of parties albeit slower.\n\nCompile the virtual machine:\n\n`make -j 8 bmr`\n\nAfter compiling the mpc file:\n\n- Run everything locally: `Scripts/bmr-program-run.sh \u003cprogram\u003e\n\u003cnumber of parties\u003e`.\n- Run on different hosts: `Scripts/bmr-program-run-remote.sh \u003cprogram\u003e\n\u003chost1\u003e \u003chost2\u003e [...]`\n\n#### Oblivious RAM\n\nYou can benchmark the ORAM implementation as follows:\n\n1) Edit `Program/Source/gc_oram.mpc` to change size and to choose\nCircuit ORAM or linear scan without ORAM.\n2) Run `./compile.py -G -D gc_oram`. The `-D` argument instructs the\ncompiler to remove dead code. This is useful for more complex programs\nsuch as this one.\n3) Run `gc_oram` in the virtual machines as explained above.\n\n## Preprocessing as required\n\nFor select protocols, you can run all required preprocessing but not\nthe actual computation. First, compile the binary:\n\n`make \u003cprotocol\u003e-offline.x`\n\nAt the time of writing the supported protocols are `mascot`,\n`cowgear`, `mal-shamir`, `semi`, `semi2k`, and `hemi`.\n\nIf you have not done so already, then compile your high-level program:\n\n`./compile.py \u003cprogram\u003e`\n\nFinally, run the parties as follows:\n\n`./\u003cprotocol\u003e-offline.x -p 0 \u0026 ./\u003cprotocol\u003e-offline.x -p 1 \u0026 ...`\n\nThe options for the network setup are the same as for the complete\ncomputation above.\n\nIf you run the preprocessing on different hosts, make sure to use the\nsame player number in the preprocessing and the online phase.\n\n## Benchmarking offline phases\n\n#### Benchmarking the MASCOT or SPDZ2k offline phase\n\nThese implementations are not suitable to generate the preprocessed\ndata for the online phase because they can only generate either\nmultiplication triples or bits.\n\nMASCOT can be run as follows:\n\n`host1:$ ./ot-offline.x -p 0 -c`\n\n`host2:$ ./ot-offline.x -p 1 -c`\n\nFor SPDZ2k, use `-Z \u003ck\u003e` to set the computation domain to Z_{2^k}, and\n`-S` to set the security parameter. The latter defaults to k. At the\ntime of writing, the following combinations are available: 32/32,\n64/64, 64/48, and 66/48.\n\nRunning `./ot-offline.x` without parameters give the full menu of\noptions such as how many items to generate in how many threads and\nloops.\n\n#### Benchmarking Overdrive offline phases\n\nWe have implemented several protocols to measure the maximal throughput for the [Overdrive paper](https://eprint.iacr.org/2017/1230). As for MASCOT, these implementations are not suited to generate data for the online phase because they only generate one type at a time.\n\nBinary | Protocol\n------ | --------\n`simple-offline.x` | SPDZ-1 and High Gear (with command-line argument `-g`)\n`pairwise-offline.x` | Low Gear\n`cnc-offline.x` | SPDZ-2 with malicious security (covert security with command-line argument `-c`)\n\nThese programs can be run similarly to `spdz2-offline.x`, for example:\n\n`host1:$ ./simple-offline.x -p 0 -h host1`\n\n`host2:$ ./simple-offline.x -p 1 -h host1`\n\nRunning any program without arguments describes all command-line arguments.\n\n##### Memory usage\n\nLattice-based ciphertexts are relatively large (in the order of megabytes), and the zero-knowledge proofs we use require storing some hundred of them. You must therefore expect to use at least some hundred megabytes of memory per thread. The memory usage is linear in `MAX_MOD_SZ` (determining the maximum integer size for computations in steps of 64 bits), so you can try to reduce it (see the compilation section for how set it). For some choices of parameters, 4 is enough while others require up to 8. The programs above indicate the minimum `MAX_MOD_SZ` required, and they fail during the parameter generation if it is too low.\n","funding_links":[],"categories":["C++","1.4 Courses","MPC-based Solutions","Software"],"sub_categories":["General MPC Frameworks","Frameworks"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdata61%2FMP-SPDZ","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdata61%2FMP-SPDZ","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdata61%2FMP-SPDZ/lists"}