[freehaven-cvs] Trim and tighten more

[nickm@seul.org (Nick Mathewson)]

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

Modified Files:
	pynchon.tex 
Log Message:
Trim and tighten more

Index: pynchon.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.56
retrieving revision 1.57
diff -u -d -r1.56 -r1.57
--- pynchon.tex	18 Sep 2004 02:49:43 -0000	1.56
+++ pynchon.tex	18 Sep 2004 03:03:12 -0000	1.57
@@ -111,7 +111,7 @@
 passes them to a {\it collator} component, which encrypts the messages and
 periodically packages them into regular batches.  These batches are
 then replicated at a number of \emph{distributor} servers, which
-use a  private information retrieval
+use a private information retrieval
 protocol to allow nym owners to receive mail while
 maintaining unlinkability between a message and its recipient.
 
@@ -182,7 +182,7 @@
 delivered, which can make the system too unreliable for practical
 use if significant time elapses between path generation and message
 origination.\footnote{Forward-only messages through a mix-net, however, are
-sufficiently reliable. The client software is able to evaluate network
+sufficiently reliable. The client software can 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.}
@@ -194,7 +194,7 @@
 remailers~\cite{hal-remailer}), such as {\tt
 alpha.c2.net}~\cite{alpha-faq} and {\tt
 nym.alias.net}~\cite{nym-alias-net}, implement a central
-reply-block repository which allowed pseudonym holders to receive messages
+reply-block repository that allowed pseudonym holders to receive messages
 delivered to a email address. Unfortunately, Type I remailers
 allow multiple uses of their reply blocks, which are vulnerable to replay and
 flooding attacks as discussed in~\cite{remailer-attacks,tcmay}
@@ -224,7 +224,7 @@
 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
+enough time and data, can reliable determine who is talking to
 whom~\cite{statistical-disclosure}.
 
 \subsubsection {Network-level client anonymity.}
@@ -328,7 +328,7 @@
 the adversary
 cannot link the user to her pseudonyms.
 
-\begin{figure}
+\begin{figure}[t]
 \begin{center}
 \includegraphics[width=10cm, height=7cm]{figs/PynFig1}
 \caption{The Pynchon Gate Architecture}
@@ -411,7 +411,7 @@
 ``bucket pool.''  To ensure integrity, each bucket contains a hash of the
 next.
 
-\begin{figure}
+\begin{figure}[t]
 \begin{center}
 \includegraphics[width=10cm, height=7.5cm]{figs/PynFig2}
 \caption{The meta-index and bucket pool}
@@ -490,9 +490,9 @@
 can XOR them to compute the bucket's contents.
 
 As an optimization, a client may send $k-1$ of the distributors a key for a
-stream cipher instead of a full bit vector. The distributors can use the
-stream in place of the vector~\cite{prng-back}.  One distributor,
-however, will still need to receive a full vector.
+stream cipher instead of a bit vector. The distributors can use the
+stream in place of the vector~\cite{prng-back,berthold}; only one
+still needs to receive a full vector.
 
 %To prevent man-in-the-middle attacks, TLS is used as the protocol's
 %transport layer~\cite{rfc-2246}. Users negotiate a TLS connection with a
@@ -519,8 +519,7 @@
 
 \section{Known attacks against pseudonymity systems}
 \label{sec:security}
-We discuss the security implications in pseudonymity systems throughout
-this paper. Most attacks on pseudonymity systems fall into one of the
+Most attacks on pseudonymity systems fall into one of the
 following categories.
 
 \subsubsection{Legal and hacking attacks.}
@@ -532,10 +531,9 @@
 encrypt incoming messages and deleting encryption keys.% Nym holders do not
 %communicate directly with the nym server, and the nym server is not
 %entrusted with any identifying information for the user.
-All sensitive data is deleted from the collator the bucket pool is generated,
+All sensitive data is deleted as the bucket pool is generated,
 ensuring that the collator has as little information
-useful to an attacker as possible, and that collator resource requirements
-are kept low.
+useful to an attacker as possible.
 
 %Messages sent from the nym server to the nym owner are
 %addressed at the collator to an opaque ID which remains unchanged for the
@@ -549,7 +547,7 @@
 key rotation it would be trivial for an attacker to archive all data sent
 to distributors, and then at some later time obtain the nym's collator
 address and key from the nym server though an active attack on those
-components. The attacker would then be able to read all messages that nym
+components. The attacker could then read all messages that nym
 has ever received.
 In the interest of retaining little information for an attacker,
 implementations should discard old secrets \emph{as soon as they are no
@@ -567,7 +565,7 @@
 security properties that normal mix-net systems may not have~\cite{minx}.
 
 The Pynchon Gate uses mix-nets for forward message delivery only. Attacks
-which do not work against a mix-net in normal forward-delivery mode will
+that do not work against a mix-net in normal forward-delivery mode will
 not impact Pynchon Gate.
 
 \subsubsection{Man-in-the-middle attacks.}
@@ -593,7 +591,7 @@
 %topology of the Pynchon Gate infrastructure further eliminates areas of
 %potential replay attack risk.
 
-\subsection{Tagging and known-cleartext attacks.} An attacker may alter
+\subsubsection{Tagging and known-cleartext attacks.} An attacker may alter
 a message, or observe the cleartext of a message, so that he may be able
 to later link an input message with a given output retrieved by the
 nym holder.
@@ -642,20 +640,20 @@
 %linking the nym with the nym holder's true name.
 
 Users of the Pynchon Gate select distributors from which to receive data
-at random, each time the nym holder retrieves her messages. As opposed to
+at random, each time the nym holder retrieves her messages. Unlike
 systems where the pseudonym infrastructure initiates the delivery of
 messages, the Pynchon Gate Client initiates the retrival of messages, and
 thus message retrieval cannot be correlated to a given nym by a malicious
 sender.
 
-Message buckets are of a fixed size, to protect against attacks similar to
-the active flooding attacks on mix-net systems~\cite {trickle02} as well
-as simple usage pattern analysis. If the number of messages contained in
-the system is too great to return in this normalized manner, delivery may
-be conducted by \emph{trickling} the pending messages to the distributors
-over the next several tree distributions. To protect against denial of
-service attacks, users can selectively retrieve or delete excess messages.
-\footnote{If a
+Message buckets are of a fixed size, to protect against
+active flooding attacks~\cite {trickle02} as well
+as simple usage pattern analysis. If the volume of messages
+is too great to fit in a users' buckets, delivery continues by
+\emph{trickling} the pending messages to the distributors
+over the next several tree distributions. To prevent denial of
+service attacks, users can selectively retrieve or delete excess
+messages.\footnote{If a
 client will be retrieving large amounts of data on a regular basis, this
 method will not work. Instead, the client should at account creation time
 request a sufficient number of buckets to receive all data destined to it.
@@ -665,9 +663,9 @@
 %A hash tree of variable depth would risk leaking usage information about
 %nym-holders. The Pynchon Gate uses a tree of a fixed depth.
 
-Since the time between the delivery of a message to the nym server and a
-reply from the nym holder may leak information about the nym holder to an
-observer, traffic from the client to the distributors is regulated by the
+Since the time between sending a message and receiving a reply
+may leak information about the nym holder,
+traffic from the client to the distributors is regulated by the
 client, which queries the distributors only at given intervals. To thwart active
 attacks against the distributor targetting a specific client, clients should
 choose these intervals randomly.
@@ -698,8 +696,8 @@
 to network when she is absent in order to link an {\it anonymous} sender
 Alice to her regular
 recipients $\mbox{Bob}_1 ...  \mbox{Bob}_N$.   Against {\it pseudonymous}
-recipients, however, these attacks are significantly easier: in the anonymity
-case we assume that many senders may send to any given recipient
+recipients, however, these attacks are far easier: in the anonymity
+case, many senders may send to any given recipient
 $\mbox{Bob}_i$, but with pseudonymous delivery, only one
 user sends or receives messages for a given pseudonym.
 
@@ -722,7 +720,7 @@
 mix-net delay variance allowed the simulated
 attacker to guess the user's identity correctly after the user received an
 average of only 37 messages.  In the best simulated case ($P_M=0.5,
-P_D=0.9,\ell=4$), the user was able to receive an average of only 1775
+P_D=0.9,\ell=4$), the user received an average of only 1775
 messages before the attacker guessed correctly.  For an active user, this is
 well within a month's expected traffic.
 
@@ -772,7 +770,7 @@
 scalability to be useful. A reasonable engineering plan is to implement
 the algorithm that we describe, then once the implementation reaches a
 level of scaling high enough to warrant the much greater difficulty of a
-more sophisticated algorithm, implement a follow-on protocol which uses fewer
+more sophisticated algorithm, implement a follow-on protocol that uses fewer
 resources. This delay is prudent, since
 % from a security standpoint, since
 %the potential effectiveness of attacks in which a distributor sends back
@@ -827,25 +825,7 @@
 this volume after compression. $S$ is the number of nodes in the
 infrastructure.
 
-Cypherpunk nym system parameters are denoted as $r$ for reply block size,
-and $\ell$ for the number of mixes in the reply block.
-
-Underhill uses a payload $P$ of size 28 kilobytes, a reply block $r$ of
-size 2 kilobytes, and a packet size $M$ of 32 kilobytes. For Underhill,
-$W$ is the maximum interval at which users must replenish reply blocks.
-Similarly, $W$ is the window of time (in days) in which users must
-retrieve their mail in Pynchon Gate.
-
-Pynchon Gate allocates buckets of size $B$. The number of message buckets
-needed ($m$) is calculated as $\sum \left\lceil
-\frac{CVol_i}{B}\right\rceil$ and the number of index buckets needed ($I$)
-is calculated as $\left\lceil \frac{N \cdot IE}{B - IE} \right\rceil$,
-where $IE$ is the index entry size. $ME$ is the system's metaindex. The
-PIR stream seed size is $SS$, and $K$ is the number of distributors chosen
-from which to retrieve data.
-
-\noindent
-\begin{figure}
+\begin{figure}[t]
 \begin{center}
 \begin{minipage}{\linewidth}
 \renewcommand{\thefootnote}{\thempfootnote}
@@ -896,6 +876,24 @@
 \caption{Performance comparison for several pseudonymity designs.}
 \label{fig:performance}
 \end{figure}
+
+Cypherpunk nym system parameters are denoted as $r$ for reply block size,
+and $\ell$ for the number of mixes in the reply block.
+
+Underhill uses a payload $P$ of size 28 kilobytes, a reply block $r$ of
+size 2 kilobytes, and a packet size $M$ of 32 kilobytes. For Underhill,
+$W$ is the maximum interval at which users must replenish reply blocks.
+Similarly, $W$ is the window of time (in days) in which users must
+retrieve their mail in Pynchon Gate.
+
+Pynchon Gate allocates buckets of size $B$. The number of message buckets
+needed ($m$) is calculated as $\sum \left\lceil
+\frac{CVol_i}{B}\right\rceil$ and the number of index buckets needed ($I$)
+is calculated as $\left\lceil \frac{N \cdot IE}{B - IE} \right\rceil$,
+where $IE$ is the index entry size. $ME$ is the system's metaindex. The
+PIR stream seed size is $SS$, and $K$ is the number of distributors chosen
+from which to retrieve data.
+
 %\section{A Note on Usability}
 %XXXX Merge into conclusion, where we evaluate our success.
 %XXXX I don't mind chopping this whole section out if we need to. -LS.
@@ -930,11 +928,11 @@
 \section{Conclusions}
 \label{sec:conclusions}
 
-We have presented a system for anonymous message retrieval which provides
-stronger anonymity assurance and greater robustness than any other
-high-latency pseudonymous message retrieval system theorized or deployed.
-This system, when properly utilized, resists traffic analysis better than
-existing deployed systems, and offers convenient scalability options.
+We have presented a system for anonymous message retrieval that provides
+stronger anonymity assurance and greater robustness than other
+theorized or deployed high-latency pseudonymous message retrieval systems.
+We traffic analysis better than
+current deployed systems, and offers convenient scalability options.
 
 We have proposed a client protocol that does not rely upon an obtrusive
 user interface. Much work remains in the field of effective user interface
@@ -947,16 +945,15 @@
 %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
-PIR systems; Adam Back, for his optimization on the message request
-protocol; Lucky Green, for valuable comments; Ben Laurie, for review of an
-early sketch of the Pynchon Gate PIR Protocol; Sonia Ara\~na, Roger
-Dingledine, Peter Palfrader, and Adam Shostack for proof-reading and
+We thank Russell O'Connor for review of several candidate
+PIR systems; Adam Back for optimizations on the message request
+protocol; Lucky Green for valuable comments; Ben Laurie for review of an
+early sketch of the PIR Protocol; Sonia Ara\~na, Roger
+Dingledine, Peter Palfrader, and Adam Shostack for proofreading and
 comments on the paper. Finally, thanks to the many members of the
-Cypherpunks mailing list who have contributed much to the field of
+Cypherpunks mailing list who have contributed to the field of
 anonymity research, in particular Jim McCoy, who has done substantial work
-in the area of alternative designs for pseudonymous message retrieval.
+in designs for pseudonymous message retrieval.
 
 
 \bibliographystyle{plain}

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