Skip to content
A fast, portable, and easy to use Oblivious Transfer Libary
Assembly C++ C Other
Branch: master
Clone or download
Peter Rindal
Peter Rindal cryptoTools updates
Latest commit e1336b2 Aug 15, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
KyberOT added Kyber and MR19 Aug 15, 2019
SimplestOT added Kyber and MR19 Aug 15, 2019
cryptoTools @ 85da63e cryptoTools updates Aug 15, 2019
frontend removed warning and unused files Aug 13, 2019
libOTe added Kyber and MR19 Aug 15, 2019
libOTe_Tests added Kyber and MR19 Aug 15, 2019
libOTe_TestsVS include bitpoly mul Aug 8, 2019
.gitignore naorPinkas uses relic by default Nov 27, 2018
.gitmodules big commit after com crash Sep 26, 2017
.travis.yml removed unit test from travis Jun 19, 2018
CMakeLists.txt added Kyber and MR19 Aug 15, 2019
LICENSE big commit after com crash Sep 26, 2017
README.md Merge branch 'master' of https://github.com/osu-crypto/libOTe Aug 13, 2019
buildAll.ps1 big commit after com crash Sep 26, 2017
copySourceToLinux.ps1 small Jan 18, 2019
icon.PNG icon Apr 10, 2019
libOTe.sln added Kyber and MR19 Aug 15, 2019
title.PNG title Apr 10, 2019
titleOSU.PNG

README.md

Build Status

A fast and portable C++11 library for Oblivious Transfer extension (OTe). The primary design goal of this library to obtain high performance while being easy to use. This library currently implements:

  • The semi-honest 1-out-of-2 OT [IKNP03].
  • The semi-honest 1-out-of-2 Delta-OT [IKNP03],[BLNNOOSS15].
  • The semi-honest 1-out-of-N OT [KKRT16].
  • The malicious secure 1-out-of-2 OT [KOS15].
  • The malicious secure 1-out-of-2 Delta-OT [KOS15],[BLNNOOSS15].
  • The malicious secure 1-out-of-N OT [OOS16].
  • The malicious secure approximate K-out-of-N OT [RR16].
  • The malicious secure 1-out-of-2 base OT [NP01].
  • The malicious secure 1-out-of-2 base OT [CO15] (Faster Linux ASM version disabled by default).

Introduction

This library provides several different classes of OT protocols. First is the base OT protocol of Naor Pinkas [NP01]. This protocol bootstraps all the other OT extension protocols. Within the OT extension protocols, we have 1-out-of-2, 1-out-of-N and K-out-of-N, both in the semi-honest and malicious settings.

All implementations are highly optimized using fast SSE instructions and vectorization to obtain optimal performance both in the single and multi-threaded setting. See the Performance section for a comparison between protocols and to other libraries.

Networking can be performed using both the sockets provided by the library and external socket classes. See the networking tutorial for an example.

Example Code

A minimal working example showing how to perform n OTs using the IKNP protocol.

void minimal()
{
    // Setup networking. See cryptoTools\frontend_cryptoTools\Tutorials\Network.cpp
    IOService ios;
    Channel senderChl = Session(ios, "localhost:1212", SessionMode::Server).addChannel();
    Channel recverChl = Session(ios, "localhost:1212", SessionMode::Client).addChannel();

    // The number of OTs.
    int n = 100;

    // The code to be run by the OT receiver.
    auto recverThread = std::thread([&]() {
        PRNG prng(sysRandomSeed());
        IknpOtExtReceiver recver;
        recver.genBaseOts(prng, recverChl);

        // Choose which messages should be received.
        BitVector choices(n);
        choices[0] = 1;
        //...

        // Receive the messages
        std::vector<block> messages(n);
        recver.receiveChosen(choices, messages, prng, recverChl);

        // messages[i] = sendMessages[i][choices[i]];
    });

    PRNG prng(sysRandomSeed());
    IknpOtExtSender sender;
    sender.genBaseOts(prng, senderChl);

    // Choose which messages should be sent.
    std::vector<std::array<block, 2>> sendMessages(n);
    sendMessages[0] = { toBlock(54), toBlock(33) };
    //...

    // Send the messages.
    sender.sendChosen(sendMessages, prng, senderChl);
    recverThread.join();
}

Performance

The running time in seconds for computing n=224 OTs on a single Intel Xeon server (2 36-cores Intel Xeon CPU E5-2699 v3 @ 2.30GHz and 256GB of RAM) as of 11/16/2016. All timings shown reflect a "single" thread per party, with the expection that network IO in libOTe is performed in the background by a separate thread.

Type Security Protocol libOTe (SHA1/AES) Encrypto Group (SHA256) Apricot (AES-hash) OOS16 (blake2) emp-toolkit (AES-hash)
1-out-of-N (N=276) malicious OOS16 10.6 / 9.2 ~ ~ 24** ~
1-out-of-N (N=2128) passive KKRT16 9.2 / 6.7 ~ ~ ~ ~
1-out-of-2 Delta-OT malicious KOS15 1.9* ~ ~ ~ ~
1-out-of-2 Delta-OT passive KOS15 1.7* ~ ~ ~ ~
1-out-of-2 malicious ALSZ15 ~ 17.3 ~ ~ 10
1-out-of-2 malicious KOS15 3.9 / 0.7 ~ 1.1 ~ 2.9
1-out-of-2 passive IKNP03 3.7 / 0.6 11.3 0.6 ~ 2.7
1-out-of-2 Base malicious CO15 1,592/~ ~ ~ ~ ~
1-out-of-2 Base malicious NP00 12,876/~ ~ ~ ~ ~

Install

The library is cross platform and has been tested on Windows, Mac and Linux. There is one mandatory dependency on Boost 1.69 (networking), and three optional dependencies on, Miracl, Relic or SimplestOT (Unix only) for Base OTs. Any or all of these dependenies can be enabled. See below.

Windows

In Powershell, this will set up the project

git clone --recursive https://github.com/osu-crypto/libOTe.git
cd libOTe/cryptoTools/thirdparty/win
getBoost.ps1 
cd ../../..
libOTe.sln

To see all the command line options, execute the program

frontend.exe

Boost and visual studio 2017: If boost does not build with visual studio 2017 follow these instructions.

Enabling Relic (for fast base OTs):

  • Clone the Visual Studio port Relic git clone https://github.com/ladnir/relic.git.
  • Use the CMake command cmake . -DMULTI=OPENMP -DCMAKE_INSTALL_PREFIX:PATH=C:\libs -DCMAKE_GENERATOR_PLATFORM=x64 generate a Visual Studio solution
  • Optional: Build with gmp/mpir for faster performance.
  • Install it to C:\libs (build the INSTALL VS project).
  • Edit the config file libOTe/cryptoTools/cryptoTools/Common/config.h to include #define ENABLE_RELIC.

Enabling Miracl (for base OTs):

  • cd libOTe/cryptoTools/thirdparty/win
  • getMiracl.ps1 (If the Miracl script fails to find visual studio 2017, manually open and build the Miracl solution.)
  • cd ../../..
  • Edit the config file libOTe/cryptoTools/cryptoTools/Common/config.h to include #define ENABLE_MIRACL.

IMPORTANT: By default, the build system needs the NASM compiler to be located at C:\NASM\nasm.exe. In the event that it isn't, there are two options, install it, or enable the pure c++ implementation:

Linux / Mac

In short, this will build the project (without base OTs)

git clone --recursive https://github.com/osu-crypto/libOTe.git
cd libOTe/cryptoTools/thirdparty/linux
bash boost.get
cd ../../..
cmake .
make

This will build the minimum version of the library (wihtout base OTs). The libraries will be placed in libOTe/lib and the binary frontend_libOTe will be placed in libOTe/bin To see all the command line options, execute the program

./bin/frontend_libOTe

Enable Base OTs using:

  • cmake . -DENABLE_MIRACL=ON: Build the library with integration to the Miracl library. Requires building miracl cd libOTe/cryptoTools/thirdparty/linux; bash miracl.get.

  • cmake . -DENABLE_RELIC=ON: Build the library with integration to the Relic library. Requires that relic is built with cmake . -DMULTI=OPENMP and installed. Requires an older version of relic found here Relic

  • Linux Only: cmake . -DENABLE_SIMPLESTOT=ON: Build the library with integration to the SimplestOT library implementing a base OT. Also works with only relic but is slower.

Other Options:

  • cmake . -DENABLE_CIRCUITS=ON: Build the library with the circuit library enabled.
  • cmake . -DENABLE_NASM=ON: Build the library with the assembly base SHA1 implementation. Requires the NASM compiler.

Note: In the case that miracl or boost is already installed, the steps cd libOTe/cryptoTools/thirdparty/linux; bash boost.get can be skipped and CMake will attempt to find them instead. Boost is found with the CMake findBoost package and miracl is found with the find_library(miracl) command.

Linking

You can either make install on linux or link libOTe's source tree. In the latter case, you will need to include the following:

  1. .../libOTe
  2. .../libOTe/cryptoTools
  3. .../libOTe/cryptoTools/thirdparty/linux/boost
  4. .../libOTe/cryptoTools/thirdparty/linux/miracl/miracl (if enabled)
  5. [Relic includes] (if enabled)

and link:

  1. .../libOTe/bin/liblibOTe.a
  2. .../libOTe/bin/libcryptoTools.a
  3. .../libOTe/bin/libSimplestOT.a (if enabled)
  4. .../libOTe/cryptoTools/thirdparty/linux/boost/stage/lib/libboost_system.a
  5. .../libOTe/cryptoTools/thirdparty/linux/boost/stage/lib/libboost_thread.a
  6. .../libOTe/cryptoTools/thirdparty/linux/miracl/miracl/source/libmiracl.a (if enabled)
  7. [Relic binar] (if enabled)

Note: On windows the linking paths follow a similar pattern.

Help

Contact Peter Rindal rindalp@oregonstate.edu for any assistance on building or running the library.

Citing

Spread the word!

@misc{libOTe,
    author = {Peter Rindal},
    title = {{libOTe: an efficient, portable, and easy to use Oblivious Transfer Library}},
    howpublished = {\url{https://github.com/osu-crypto/libOTe}},
}

Protocol Details

The 1-out-of-N [OOS16] protocol currently is set to work forn N=276 but is capable of supporting arbitrary codes given the generator matrix in text format. See ./libOTe/Tools/Bch511.txt for an example.

The 1-out-of-N [KKRT16] for arbitrary N is also implemented and slightly faster than [OOS16]. However, [KKRT16] is in the semi-honest setting.

The approximate K-out-of-N OT [RR16] protocol is also implemented. This protocol allows for a rough bound on the value K with a very light weight cut and choose technique. It was introduced for a PSI protocol that builds on a Garbled Bloom Filter.

* Delta-OT does not use the RandomOracle or AES hash function.

** This timing was taken from the [OOS16] paper and their implementation used multiple threads. The number was not specified. When using the libOTe implementation with multiple threads, a timing of 2.6 seconds was obtained with the RandomOracle hash function.

It should be noted that the libOTe implementation uses the Boost ASIO library to perform more efficient asynchronous network IO. This involves using a background thread to help process network data. As such, this is not a completely fair comparison to the Apricot implementation but we don't expect it to have a large impact. It also appears that the Encrypto Group implementation uses asynchronous network IO.

The above timings were obtained with the follwoing options:

1-out-of-2 malicious:

  • Apricot: ./ot.x -n 16777216 -p 0 -m a -l 100 & ./ot.x -p 1 -m a -n 16777216 -l 100
  • Encrypto Group: ./ot.exe -r 0 -n 16777216 -o 1 & ./ot.exe -r 1 -n 16777216 -o 1
  • emp-toolkit: 2x 223 ./mot 0 1212 & ./mot 1 1212

1-out-of-2 semi-honest:

  • Apricot: ./ot.x -n 16777216 -p 0 -m a -l 100 -pas & ./ot.x -p 1 -m a -n 16777216 -l 100 -pas
  • Encrypto Group: ./ot.exe -r 0 -n 16777216 -o 0 & ./ot.exe -r 1 -n 16777216 -o 0
  • emp-toolkit: 2 * 223 ./shot 0 1212 & ./shot 1 1212

License

This project has been placed in the public domain. As such, you are unrestricted in how you use it, commercial or otherwise. However, no warranty of fitness is provided. If you found this project helpful, feel free to spread the word and cite us.

Citation

[IKNP03] - Yuval Ishai and Joe Kilian and Kobbi Nissim and Erez Petrank, Extending Oblivious Transfers Efficiently.

[KOS15] - Marcel Keller and Emmanuela Orsini and Peter Scholl, Actively Secure OT Extension with Optimal Overhead. eprint/2015/546

[OOS16] - Michele Orrù and Emmanuela Orsini and Peter Scholl, Actively Secure 1-out-of-N OT Extension with Application to Private Set Intersection. eprint/2016/933

[KKRT16] - Vladimir Kolesnikov and Ranjit Kumaresan and Mike Rosulek and Ni Trieu, Efficient Batched Oblivious PRF with Applications to Private Set Intersection. eprint/2016/799

[RR16] - Peter Rindal and Mike Rosulek, Improved Private Set Intersection against Malicious Adversaries. eprint/2016/746

[BLNNOOSS15] - Sai Sheshank Burra and Enrique Larraia and Jesper Buus Nielsen and Peter Sebastian Nordholt and Claudio Orlandi and Emmanuela Orsini and Peter Scholl and Nigel P. Smart, High Performance Multi-Party Computation for Binary Circuits Based on Oblivious Transfer. eprint/2015/472

[ALSZ15] - Gilad Asharov and Yehuda Lindell and Thomas Schneider and Michael Zohner, More Efficient Oblivious Transfer Extensions with Security for Malicious Adversaries. eprint/2015/061

[NP01] - Moni Naor, Benny Pinkas, Efficient Oblivious Transfer Protocols.

You can’t perform that action at this time.