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.14  
    1.15  Security Assumptions
    1.16  --------------------
    1.17 @@ -36,40 +35,45 @@
    1.18  include:
    1.19  
    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.29  
    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.36  
    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.45  
    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.50  
    1.51  Architecture
    1.52  ------------
    1.53  
    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.64  
    1.65  Layers
    1.66  """"""
    1.67  
    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.78  
    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.83  
    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.87  
    1.88  - Runtime layer: The runtime deals with Python integers or shares.
    1.89