Home

Awesome

TinyLEGO Implementation

This is the C++14 implementation of the modified TinyLEGO [1] protocol appearing in the paper "Constant Round Maliciously Secure 2PC with Function-independent Preprocessing using LEGO" [2]. The code has been authored by Roberto Trifiletti and builds on the SplitCommit implementation of the FJNT16 additively homomorphic commitment scheme [3].

Description

The implementation was written with the purpose of exploring the practical efficiency of the TinyLEGO protocol for general secure two-party computation (2PC). It should therefore be treated as a prototype and we make no claim about actual security guarantees for any real world use cases. The code includes main and test functions that exhibit how to use the underlying commitment and 2PC code can be used. Included is also circuit representations of common cryptographic functions (available from https://www.cs.bris.ac.uk/Research/CryptographySecurity/MPC/) that are typically used for benchmarking MPC protocols. At this time the implementation has a few limitations compared to the full potential of the general protocol:

Installation

The code has been tested to work on MAC OSX 10.11 (El Capitan), macOS 10.12 (Sierra), Amazon Linux 2016.03, Ubuntu 14.04, and Ubuntu 16.04.

Requirements

The above can be installed via a package manager, i.e. apt on Ubuntu, yum on Amazon Linux and Homebrew on OSX are typical.

After installing the above prerequisites the code can be built with the provided script cmake-release.sh. To verify everything is working the script test/test-all.sh can afterwards be run. If all tests succeed you are good to go.

Running the main files

Two main files are produced during compilation, build/release/Tinyconst and build/release/Tinyeval. An example run of the two clients on different machines could be

The above code precomputes enough AND gates for 100 secure computations of AES-128 (including key-expansion). The -e parameters specifies how many parallel executions this should be split into for the independent preprocessing, dependent preprocessing and online phase, respectively. In this example 8 parallel threads will produce the preprocessing required for 100 AES computations, 4 parallel threads will then build 25 AES circuits each using soldering and finally 2 parallel threads will evaluate 50 AES each. In order to measure latency for sequential evaluations the last argument of e should be 1. For information about which execution arguments were used for the results provided in [2] we refer to the timing_scripts folder as the performance benefit of the chosen execution parameters is highly platform and network dependent.

References