changeset 1419:f264239b594d

viff: removed text made redundant by cf1d7d3eab0a
author Martin Geisler <>
date Mon, 14 Dec 2009 16:36:37 +0100
parents cbfa7ea6dae7
children f463223ea803
files viff/
diffstat 1 files changed, 1 insertions(+), 106 deletions(-) [+]
line wrap: on
line diff
--- a/viff/	Mon Dec 14 13:01:24 2009 +0100
+++ b/viff/	Mon Dec 14 16:36:37 2009 +0100
@@ -1,4 +1,4 @@
-# Copyright 2007, 2008 VIFF Development Team.
+# Copyright 2007, 2008, 2009 VIFF Development Team.
 # This file is part of VIFF, the Virtual Ideal Functionality Framework.
@@ -20,111 +20,6 @@
 VIFF is a Python framework for writing multi-party computations (MPC)
 in an easy, efficient, and secure way.
-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. And since
-no attacks can occur in the ideal world, no attacks can occur in the
-real world as well. Such a multi-party computation (MPC) is called a
-secure multi-party computation (SMPC).
-Security Assumptions
-Please note that like all cryptographic systems, VIFF is only secure
-as long as certain assumptions are fulfilled. These assumptions
-  - The adversary can only corrupt up to a certain threshold of the
-    total number of players. The threshold will normally be 1/2 of the
-    players, so for three players, at most one player may be
-    corrupted (there must be an honest majority).
-  - 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 adversary is passive. Being passive means that the adversary
-    only monitors the network traffic, but still follows the protocol.
-    We plan to add support for active (Byzantine) adversaries in a
-    future version.
-The precise assumptions for each protocol will eventually be included
-in the documentation for the corresponding method, but this has not
-yet been done.
-VIFF consists of several modules. The L{passive} and L{active} modules
-contain the L{PassiveRuntime} and L{ActiveRuntime} classes in which
-the main functionality is implemented. The L{runtime} module contain
-the L{Share} class and other infrastructure for the two runtime
-classes. The L{field} module contains implementations of finite fields
---- these are the values inside the shares. Other modules provide
-support functions.
-The main functionality in VIFF is implemented in the L{PassiveRuntime}
-class. This class offers methods to do addition, multiplication, etc.
-These methods operate on L{Share} instances.
-Shares hold either L{field.GF} or L{GF256} elements and are created
-from the C{shamir_share} or C{prss_share} Runtime methods. Shares
-overload the standard arithmetic operators, so you can write C{a + b -
-c * d} with four shares, and it will be translated correctly into the
-appropriate method calls on the Runtime instance associated with the
-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 L{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.
-Getting into VIFF
-As explained above, the main functionality in VIFF is the
-L{PassiveRuntime} class, so please start there. Also, be sure to
-checkout the example applications distributed in the C{apps}
-@authors: U{VIFF Development Team <>}
-@see: U{}
 __version__ = '0.7.1'