Mercurial > viff
changeset 1412:cf1d7d3eab0a
doc: updated overview
author | Martin Geisler <mg@cs.au.dk> |
---|---|
date | Mon, 14 Dec 2009 10:52:33 +0100 |
parents | b4ed28fc63d5 |
children | 184e9ed7cc5c |
files | doc/overview.txt |
diffstat | 1 files changed, 27 insertions(+), 23 deletions(-) [+] |
line wrap: on
line diff
--- a/doc/overview.txt Mon Dec 14 10:30:24 2009 +0100 +++ b/doc/overview.txt Mon Dec 14 10:52:33 2009 +0100 @@ -23,10 +23,9 @@ 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). +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 -------------------- @@ -36,40 +35,45 @@ include: - 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). + total number of players. The threshold is 1/2 of the players for + :mod:`viff.passive` and 1/3 of the players for :mod:`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. + only polynomial time adversaries are allowed. The BGW protocol used + in :mod:`viff.passive` is information theoretically secure, but we + still use cryptographic tools such as SSL to implement it. -- 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 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 for the corresponding method, but this has not -yet been done. +in the documentation, but this has not yet been done in all cases. Architecture ------------ VIFF consists of several modules. The :mod:`viff.runtime` module -contains the :class:`Runtime <viff.runtime.Runtime>` and :class:`Share -<viff.runtime.Share>` classes, in which the main functionality is -implemented. The :mod:`viff.field` module contains implementations of -finite fields --- these are the values inside the shares. Other +contains the :class:`~viff.runtime.Runtime` and +:class:`~viff.runtime.Share` classes, in which the main functionality +is implemented. The :mod:`viff.field` module contains implementations +of finite fields --- these are the values inside the shares. Other modules provide support functions. Layers """""" -The main functionality in VIFF is implemented in the :class:`Runtime -<viff.runtime.Runtime>` class. This class offers methods to do -addition, multiplication, etc. These methods operate on :class:`Share -<viff.runtime.Share>` instances. +The basic functionality in VIFF is implemented in the +:class:`~viff.runtime.Runtime` class. This class offers methods to do +simple network communication. The +:class:`~viff.passive.PassiveRuntime` class implements the BGW +protocol and offers methods for addition, multiplication, etc. These +methods operate on :class:`~viff.runtime.Share` instances. Shares hold either :class:`GFElement <viff.field.GF>` or :class:`~viff.field.GF256` elements and are created from the @@ -89,7 +93,7 @@ So in a nutshell, VIFF has these layers: - Top-level layer for application programs: There you manipulate - Python integers or :class:`viff.runtime.Share` instances. + Python integers or :class:`~viff.runtime.Share` instances. - Runtime layer: The runtime deals with Python integers or shares.