Overview

VIFF allows you to write a program which will interact with other programs in order to execute a joint computation. This is called a multi-party computation, MPC for short.

The programs will implement what we call a virtual ideal functionality (IF). The idea is that the behavior of the programs should be indistinguishable from the behavior of programs interacting with a so-called ideal functionality. An ideal functionality is a player that cannot be corrupted, also known as a trusted third party (TTP).

Interacting with an IF is easy: all players give their inputs to the IF, which computes the results. The results are then distributed to the correct players. The inputs and the results are sent over secure channels, and since the IF cannot be corrupted, this ideal protocol must be secure.

In the real world there is no IF, but VIFF allows you to implement a virtual ideal functionality. The behavior of a bunch of programs using VIFF is indistinguishable from program running in the ideal world. It is indistinguishable in the sense that everything that can happen in the real world protocol could happen in the ideal world too. Since no attacks can occur in the ideal world, no attacks can occur in the real world as well. We call this a secure multi-party computation (MPC).

Security Assumptions

Please note that like all cryptographic systems, VIFF is only secure as long as certain assumptions are fulfilled. These assumptions include:

• The adversary can only corrupt up to a certain threshold of the total number of players. The threshold is 1/2 of the players for viff.passive and 1/3 of the players for viff.active. This means that you need three players to tolerate one corruption (there must be an honest majority) for security against and passive adversary and four players for security against an active adversary.
• The adversary is computationally bounded. The protocols used by VIFF rely on certain computational hardness assumptions, and therefore only polynomial time adversaries are allowed. The BGW protocol used in viff.passive is information theoretically secure, but we still use cryptographic tools such as SSL to implement it.
• The adversary is passive or active, depending on the protocol. Being passive means that the adversary only monitors the network traffic, but still follows the protocol. An active adversary is allowed to deviated from the protocol in arbitrary ways.

The precise assumptions for each protocol will eventually be included in the documentation, but this has not yet been done in all cases.

Architecture

VIFF consists of several modules. The viff.runtime module contains the Runtime and Share classes, in which the main functionality is implemented. The viff.field module contains implementations of finite fields — these are the values inside the shares. Other modules provide support functions.

Layers

The basic functionality in VIFF is implemented in the Runtime class. This class offers methods to do simple network communication. The PassiveRuntime class implements the BGW protocol and offers methods for addition, multiplication, etc. These methods operate on Share instances.

Shares hold either GFElement or GF256 elements and are created from the shamir_share() or prss_share() Runtime methods. Shares overload the standard arithmetic operators, so you can write a + b - c * d with four shares, and it will be translated correctly into the appropriate method calls on the Runtime associated with the shares.

A field element contain the concrete value on which we do calculations. This is just a normal Python (long) integer. The value is wrapped in an object that will keep track of doing modulo reductions as appropriate.

So in a nutshell, VIFF has these layers:

• Top-level layer for application programs: There you manipulate Python integers or Share instances.
• Runtime layer: The runtime deals with Python integers or shares.
• Field elements: Deals with arithmetic over Python integers, but with modulo reductions as needed.