[freehaven-cvs] Fixed lots of typos and grammar issues. Now preach l...

[rabbi@seul.org]

Update of /home2/freehaven/cvsroot/doc/pynchon-gate
In directory moria.mit.edu:/tmp/cvs-serv29911

Modified Files:
	pynchon.tex 
Log Message:
Fixed lots of typos and grammar issues. Now preach less.


Index: pynchon.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -d -r1.10 -r1.11
--- pynchon.tex	27 Jan 2004 03:12:43 -0000	1.10
+++ pynchon.tex	27 Jan 2004 05:00:11 -0000	1.11
@@ -53,7 +53,7 @@
 of anonymous mail retrieval.
 
 The system we propose consists of a number of components. The \emph{nym
-server} component interfaces with the email network; it delivers mail to
+server} component interfaces with the email network: it delivers mail to
 external email addresses from authenticated nym owners, receives mail for
 nym accounts, and processes administrative \emph{control messages} related
 to individual nym accounts. Incoming email is passed from the nym server
@@ -67,7 +67,7 @@
 
 While sender-anonymity systems such as Mixmaster~\cite{mixmaster-spec}
 have been available for public use for nearly a decade, there remains a
-need for a secure, robust system which will allow users to receive mail
+need for a secure, robust system that will allow users to receive mail
 anonymously. The system should be of equivalent or greater security than
 the state of the art for forward message anonymity; should gracefully
 handle node failure without loss of mail; should be resistant to attack
@@ -83,10 +83,10 @@
 component nodes of the mix being operational in order for mail to be
 delivered. This makes the system too unreliable for practical
 use.\footnote{Forward-only messages through a mix-net, however, are
-sufficiently reliable, since the client software is able to evaluate
-network health information~\cite{echolot} before sending a message, and
-thus can construct robust remailer chains based on the current health of
-the remailer network.}
+sufficiently reliable. The client software is able to evaluate network
+health information~\cite{echolot} before sending a message, and thus can
+construct robust remailer chains based on the current health of the
+remailer network.}
 
 In addition to reliability issues, simple reply-block systems suffer from
 a pseudonym management perspective. Cypherpunk nym servers based on the
@@ -96,9 +96,9 @@
 nym.alias.net}~\cite{nym-alias-net}, implemented the concept of a central
 reply-block repository which allowed pseudonym-holders to receive messages
 delivered to a traditional email address. Unfortunately, reply-block
-systems based Type I remailers allow multiple-use reply blocks. Attacks on
-multiple-use reply blocks are discussed in~\cite{remailer-attacks}. For a
-system to permit multiple-use reply blocks, it must inherently risk
+systems based on Type I remailers allow multiple-use reply blocks. Attacks
+on multiple-use reply blocks are discussed in~\cite{remailer-attacks}. For
+a system to permit multiple-use reply blocks, it must inherently risk
 replay-attacks~\cite{tcmay}. The Type I anonymous remailer system suffers
 greatly because of this. Type II (Mixmaster) and Type III
 (Mixminion~\cite{mixminion}) systems do not permit multiple-use reply
@@ -108,21 +108,22 @@
 
 While the Type II system does not have any means of support for anonymous
 reply blocks, the Type III system introduces single-use reply blocks
-(SURBs)~\cite{surb} as a means of avoiding the replay attack issues.
-Mixminion requires the recipient to create a large number of reply blocks
-to be used by those who wish to send her mail. In practice, this is likely
-to be automated by a nym server~\cite{pop-mix} which will handle the
-storage of SURBs and transfer of pseudonymous mail through the remailer
-network to the recipient. The technique used in Mixminion also has the
-property that the forward and reply messages share the same anonymity set,
-which is a significant security improvement over Type I. However, since
-reply blocks are still being used, the reliability issues remain.\footnote
-{If any given node in the pre-selected SURB is defunct at the time mail is
-set to be delivered, the mail will be lost.} Reply block systems are also
-susceptible to intersection attacks~\cite{disad-free-routes}. A global
-observer can collect data on who is sending and receiving mail, and given
-enough time and data, will be able to reliably determine who is talking to
-whom via statistical correlation~\cite{statistical-disclosure}.
+(SURBs)~\cite{surb} as a means of avoiding the replay attack issues. The
+Type III protocol requires the recipient to create a large number of reply
+blocks to be used by those who wish to send her mail. In practice, this is
+likely to be automated by a nym server~\cite{pop-mix} which will handle
+the storage of SURBs and transfer of pseudonymous mail through the
+remailer network to the recipient. The technique used in Type III also has
+the property that the forward and reply messages share the same anonymity
+set, which is a significant security improvement over Type I. However,
+since reply blocks are still being used, the reliability issues
+remain.\footnote {If any given node in the pre-selected SURB is defunct at
+the time mail is set to be delivered, the mail will be lost.} Reply block
+systems are also susceptible to intersection
+attacks~\cite{disad-free-routes}. A global observer can collect data on
+who is sending and receiving mail, and given enough time and data, will be
+able to reliably determine who is talking to whom via statistical
+correlation~\cite{statistical-disclosure}.
 
 
 \subsubsection {Network-level client anonymity.}
@@ -130,14 +131,14 @@
 The ZKS Freedom Network~\cite{freedom2-arch} provided anonymous IP access
 to a POP3 server~\cite{freedom2-mail}, enabling its users to maintain
 pseudonyms using standard email protocols. Freedom was discontinued due to
-the high expense of operating the network, mainly due to bandwidth costs.
-Other network-level anonymity systems, such as Pipenet~\cite{pipenet} and
-Onion Routing~\cite{goldschlag96} could be used in much the same fashion;
-unfortunately, they also suffer the same barriers to
-deployment~\cite{fiveyearslater}. Low-latency anonymity systems such as
-these are also at greater risk of failure than the low-latency mixes, and
-are more susceptible to traffic analysis attacks~\cite
-{danezis-traffic-analysis}.
+the high expense of operating the network, in particular the bandwidth
+costs. Other network-level anonymity systems, such as
+Pipenet~\cite{pipenet} and Onion Routing~\cite{goldschlag96} could be used
+in much the same fashion; unfortunately, they also suffer the same
+barriers to deployment~\cite{fiveyearslater}. Low-latency anonymity
+systems such as these are also at greater risk of failure than the
+high-latency mixes, and are more susceptible to traffic analysis
+attacks~\cite {danezis-traffic-analysis}.
 
 \subsubsection{Network-level server anonymity.}
 
@@ -146,7 +147,7 @@
 allow users to offer location-hidden services. A user wishing to
 anonymously receive messages could operate an email server in a
 location-hidden fashion. Messages would be delivered to the server over
-the onion routing network, and successful delivery would not require the
+the Onion Routing network, and successful delivery would not require the
 sender to know the IP address of the destination server.
 
 Rendezvous points offer an alternative method of leveraging network-level
@@ -225,7 +226,7 @@
 able to make a series of requests from several distributor nodes, enabling
 her to receive her message without the individual nodes determining the
 identity of the pseudonym being requested. The protocol used is resistant
-to collusion; even if there are $(k-1)$ nodes operated by the adversary
+to collusion: even if there are $(k-1)$ nodes operated by the adversary
 the adversary cannot learn the requested pseudonym.
 
 By using a PIR-based message retrieval system we retain the convenience,
@@ -257,8 +258,8 @@
 authenticating control messages related to the nym email address.
 Similarly, the account creation process establishes a \emph{dynamic shared
 secret}, used to encrypt messages to the nym owner. To achieve forward
-secrecy, each time the dynamic shared secret is used, it is then changed
-to the hash of its current value.
+secrecy, each time the dynamic shared secret is used it is subsequently
+changed to the hash of its current value.
 
 Messages sent from the nym owner to the nym server include a simple MAC to
 authenticate them; they are encrypted at the anonymous mail forwarding
@@ -279,11 +280,11 @@
 
 Messages for nym owners are passed to the collator component.\footnote{The
 collator component typically resides on the same physical server as the
-nym server.} The collator component organizes all messages into a tree
-structure, with messages sorted by publicly viewable identifiers derived
-from the dynamic shared secrets. Nodes in the tree are organized into
-fixed-size \emph{buckets}. The collator then publishes metadata about the
-tree as a whole in a widely available manner.
+nym server component.} The collator component organizes all messages into
+a tree structure, with messages sorted by publicly viewable identifiers
+derived from the dynamic shared secrets. Nodes in the tree are organized
+into fixed-size \emph{buckets}. The collator then publishes metadata about
+the tree as a whole in a widely available manner.
 
 \subsection{The Distributor Nodes}
 
@@ -439,38 +440,37 @@
 buckets put together, with the limiting factor on that being the
 distributor's hard drive throughput.
 
-In order to minimize distributor response latency, the distributor can do
-continuous linear scans of the whole database and start computing the
-result of a request which comes in regardless of where it happens to be in
-the scan, finishing when the next scan returns to that point again, thus
-making the latency exactly the time of one full scan.
+An optimization can be made to minimize distributor response latency. By
+performing continuous linear scans of the entire database, the distributor
+can begin computing the result of a request at any point during the scan,
+finishing when the next scan returns to that same point. Thus the latency
+is exactly the time of one full scan.
 
 \section{A Note on Usability}
 
 The most popular pseudonym system ever deployed was {\tt
 anon.penet.fi}~\cite{helsingius}. This system provided users with an easy,
-reliable way to receive mail while hiding their true identity and email
-address. Subsequent attempts at providing more secure pseudonymous mail
+reliable way to receive mail while hiding their true identities and email
+addresses. Subsequent attempts at providing more secure pseudonymous mail
 systems have had several orders of magnitude fewer users than {\tt
 anon.penet.fi}. We believe that usability is a security consideration: if a
 system is not usable, it will not provide practical benefit. Usability is
-of particularly great concern when discussing anonymity systems; as the
+of particularly great concern when discussing anonymity systems. As the
 number of users of an anonymity system increase, the security of the
 system also increases due to the growth in the anonymity set. We believe
 that the strongest benefit to this system will be the likelihood that it
 will meet the usability and reliability needs of far more users than other
 systems, thus making it more secure based on popularity alone.
 
-This system can be implemented in
-a \emph{zero UI} manner with regard to daily use. For instance, we intend
-to implement our prototype as an application which runs in the background
-and retrieves messages from the distribution nodes at fixed intervals. The
-application will provide a local POP3 server interface so that the user
-need only configure his existing mail client to retrieve mail from his
-local machine over POP3. Multiple nyms can be managed in this manner, and
-the user will only need to interact directly with our prototype when
-configuring new nyms, or addressing client warnings regarding abnormal
-server behavior.
+This system can be implemented in a \emph{zero UI} manner with regard to
+daily use. We intend to implement our prototype as an application which
+runs in the background and retrieves messages from the distribution nodes
+at fixed intervals. The application will provide a local POP3 server
+interface so that the user need only configure his existing mail client to
+retrieve mail from his local machine over POP3. Multiple nyms can be
+managed in this manner, and the user will only need to interact directly
+with our prototype when configuring new nyms, or addressing client
+warnings regarding abnormal server behavior.
 
 We believe that such simplicity in the user interaction experience is a
 necessary component to the security of the system.
@@ -488,12 +488,14 @@
 privacy and anonymity systems, particularly when the privacy component is
 viewed by the user as optional~\cite {sassaman-lisa}. We have made some
 initial suggestions for a basic client architecture which can achieve
-optimal unobtrusiveness; we recognize that there is likely to be
-significant UI design work remaining. As it is our intent to build and
-deploy a system based on the principles of The Pynchon Gate, it is
-imperative that its effectiveness not be undermined by a poor user
-interface. The most secure system provides no value if it is not used.
+optimal unobtrusiveness, but we recognize that there is likely to be
+significant UI design work remaining. 
 
+%As it is our intent to build and
+%deploy a system based on the principles of The Pynchon Gate, it is
+%imperative that its effectiveness not be undermined by a poor user
+%interface. The most secure system provides no value if it is not used.
+%
 \section{Acknowledgments}
 
 We would like to thank Russell O'Connor, for review of several candidate

***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs       in the body. http://freehaven.net/