1.1 --- a/doc/overview.txt Mon Dec 14 10:30:24 2009 +0100
1.2 +++ b/doc/overview.txt Mon Dec 14 10:52:33 2009 +0100
1.3 @@ -23,10 +23,9 @@
1.4 virtual ideal functionality. The behavior of a bunch of programs using
1.5 VIFF is indistinguishable from program running in the ideal world. It
1.6 is indistinguishable in the sense that everything that can happen in
1.7 -the real world protocol could happen in the ideal world too. And since
1.8 -no attacks can occur in the ideal world, no attacks can occur in the
1.9 -real world as well. Such a multi-party computation (MPC) is called a
1.10 -secure multi-party computation (SMPC).
1.11 +the real world protocol could happen in the ideal world too. Since no
1.12 +attacks can occur in the ideal world, no attacks can occur in the real
1.13 +world as well. We call this a secure multi-party computation (MPC).
1.15 Security Assumptions
1.17 @@ -36,40 +35,45 @@
1.20 - The adversary can only corrupt up to a certain threshold of the
1.21 - total number of players. The threshold will normally be 1/2 of the
1.22 - players, so for three players, at most one player may be corrupted
1.23 - (there must be an honest majority).
1.24 + total number of players. The threshold is 1/2 of the players for
1.25 + :mod:`viff.passive` and 1/3 of the players for :mod:`viff.active`.
1.26 + This means that you need three players to tolerate one corruption
1.27 + (there must be an honest majority) for security against and passive
1.28 + adversary and four players for security against an active adversary.
1.30 - The adversary is computationally bounded. The protocols used by VIFF
1.31 rely on certain computational hardness assumptions, and therefore
1.32 - only polynomial time adversaries are allowed.
1.33 + only polynomial time adversaries are allowed. The BGW protocol used
1.34 + in :mod:`viff.passive` is information theoretically secure, but we
1.35 + still use cryptographic tools such as SSL to implement it.
1.37 -- The adversary is passive. Being passive means that the adversary
1.38 - only monitors the network traffic, but still follows the protocol.
1.39 - We plan to add support for active (Byzantine) adversaries in a
1.40 - future version.
1.41 +- The adversary is passive or active, depending on the protocol. Being
1.42 + passive means that the adversary only monitors the network traffic,
1.43 + but still follows the protocol. An active adversary is allowed to
1.44 + deviated from the protocol in arbitrary ways.
1.46 The precise assumptions for each protocol will eventually be included
1.47 -in the documentation for the corresponding method, but this has not
1.48 -yet been done.
1.49 +in the documentation, but this has not yet been done in all cases.
1.54 VIFF consists of several modules. The :mod:`viff.runtime` module
1.55 -contains the :class:`Runtime <viff.runtime.Runtime>` and :class:`Share
1.56 -<viff.runtime.Share>` classes, in which the main functionality is
1.57 -implemented. The :mod:`viff.field` module contains implementations of
1.58 -finite fields --- these are the values inside the shares. Other
1.59 +contains the :class:`~viff.runtime.Runtime` and
1.60 +:class:`~viff.runtime.Share` classes, in which the main functionality
1.61 +is implemented. The :mod:`viff.field` module contains implementations
1.62 +of finite fields --- these are the values inside the shares. Other
1.63 modules provide support functions.
1.68 -The main functionality in VIFF is implemented in the :class:`Runtime
1.69 -<viff.runtime.Runtime>` class. This class offers methods to do
1.70 -addition, multiplication, etc. These methods operate on :class:`Share
1.71 -<viff.runtime.Share>` instances.
1.72 +The basic functionality in VIFF is implemented in the
1.73 +:class:`~viff.runtime.Runtime` class. This class offers methods to do
1.74 +simple network communication. The
1.75 +:class:`~viff.passive.PassiveRuntime` class implements the BGW
1.76 +protocol and offers methods for addition, multiplication, etc. These
1.77 +methods operate on :class:`~viff.runtime.Share` instances.
1.79 Shares hold either :class:`GFElement <viff.field.GF>` or
1.80 :class:`~viff.field.GF256` elements and are created from the
1.81 @@ -89,7 +93,7 @@
1.82 So in a nutshell, VIFF has these layers:
1.84 - Top-level layer for application programs: There you manipulate
1.85 - Python integers or :class:`viff.runtime.Share` instances.
1.86 + Python integers or :class:`~viff.runtime.Share` instances.
1.88 - Runtime layer: The runtime deals with Python integers or shares.