[freehaven-cvs] Fix some typos, add some omitted citations. This und...

[rabbi@seul.org]

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

Modified Files:
	pynchon.tex pynchon.bib 
Log Message:
Fix some typos, add some omitted citations. This undoubtedly puts us over 
15 pages, but let's wait to see what the reviewers have to say before 
worrying about that.


Index: pynchon.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.65
retrieving revision 1.66
diff -u -d -r1.65 -r1.66
--- pynchon.tex	18 Sep 2004 03:30:59 -0000	1.65
+++ pynchon.tex	20 Sep 2004 11:04:09 -0000	1.66
@@ -87,15 +87,16 @@
 \section{Introduction} 
 Pseudonymous messaging services seek to provide users with a way to send
 messages that originate at a pseudonymous address (or ``nym'') unlinked to
-the user, and to receive messages send to that address, without allowing
+the user, and to receive messages sent to that address, without allowing
 an attacker to deduce which users are associated with which pseudonyms.
 These systems can be used specifically to provide a mechanism for a user
 to communicate without revealing her identity, or can be used as a
-building-block for other systems that need a bi-directional communication
-channel, such as Free Haven~\cite{freehaven-berk}. But, as we will argue
-below, most existing deployed solutions are either vulnerable to traffic
-analysis, or require unacceptably large amounts of bandwidth and storage
-as the number of users and volume of traffic increase.
+building-block for other systems that need a bi-directional anonymous
+communication channel, such as Free Haven~\cite{freehaven-berk}. But, as
+we will argue below, most existing deployed solutions are either
+vulnerable to traffic analysis or require unacceptably large amounts of
+bandwidth and storage as the number of users and volume of traffic
+increase.
 
 We propose the Pynchon Gate, a design that uses private information
 retrieval (PIR)~\cite{pir} primitives to build a secure, fault-tolerant
@@ -113,7 +114,7 @@
 protocol to allow nym owners to receive mail while
 maintaining unlinkability between a message and its recipient.
 
-\subsubsection{Goals}
+\subsubsection{Goals.}
 First, our design must be {\it secure}: we want the Pynchon Gate to
 resist active and passive attacks at least as well as the state of the art
 for forward message anonymity.  Thus, we should protect users' identities
@@ -130,7 +131,7 @@
 than volunteer servers can provide or users are willing to use; and
 that we should not require a complicated interface.
 
-\subsubsection{In this paper}
+\subsubsection{In this paper.}
 We begin in Section~\ref{sec:background} with a discussion of related work,
 and an overview of known attacks against existing pseudonymity systems.  (To
 motivate our work, Subsection~\ref{subsec:disclosure} presents new analysis
@@ -141,7 +142,7 @@
 subsection~\ref{subsec:protocol-design}.  In Section~\ref{sec:security} we
 analyze security, and in Section~\ref{sec:performance} we discuss
 optimizations and compare our performance to that of other pseudonymous
-message systems.)  We close with an evaluation of our design in
+message systems. We close with an evaluation of our design in
 Section~\ref{sec:conclusions}.
 
 \section{Background and attacks}
@@ -195,7 +196,7 @@
 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}
+flooding attacks as discussed in~\cite{remailer-attacks,tcmay}. 
 %The Type I anonymous remailer system suffers
 %greatly because of this. 
 Type II (Mixmaster) and Type III
@@ -222,7 +223,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, can reliable determine who is talking to
+enough time and data, can reliably determine who is talking to
 whom~\cite{statistical-disclosure}.
 
 \subsubsection {Network-level client anonymity.}
@@ -355,8 +356,8 @@
 messages for the nym owners at their specified email addresses.
 
 Nym servers manage email accounts for pseudonyms.
-For each pseudonym, the nym server stores a long-term
-public key used by the nym holder to
+For each pseudonym, the nym server stores a \emph{long-term
+public key} used by the nym holder to
 encrypt and authenticate outgoing email and administrative messages.
 Similarly, nym server stores a \emph{short-term shared secret}
 for each account, used to encrypt messages to the nym holder.
@@ -404,7 +405,7 @@
 order), the first message bucket containing that user's messages, and a
 digest of that bucket.  Finally, the meta-index lists, for each index bucket,
 the first and last $\UserID$ in that bucket, and a digest of that bucket
-(ee Figure~\ref{fig:tree}).
+(see Figure~\ref{fig:tree}).
 The index buckets and the message buckets together comprise the cycle's
 ``bucket pool.''  To ensure integrity, each bucket contains a hash of the
 next.
@@ -470,8 +471,8 @@
 
 The protocol runs as follows: after choosing distributors, the client
 establishes an encrypted connection to each
-(e.g., using TLS).  These connections must be unidirectionally authenticated
-to prevent man-in-the-middle attacks, and can be made sequentially, or in
+(e.g., using TLS~\cite{rfc-2246}).  These connections must be unidirectionally authenticated
+to prevent man-in-the-middle attacks, and can be made sequentially or in
 parallel.
 
 The client the client sends a different ``random-looking'' bit vector
@@ -487,10 +488,10 @@
 randomly.) When the client receives the corresponding $R(v_{sb})$ values, she
 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 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.
+As an optimization, a client may send $k-1$ of the distributors a key for
+a 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
@@ -520,13 +521,14 @@
 Most attacks on pseudonymity systems fall into one of the
 following categories.
 
-\subsubsection{Legal and hacking attacks.}
+\subsubsection{Legal and hacking attacks.} 
 Attackers may attempt to coerce the operators of pseudonymity systems
-through lawsuits or other means~\cite{nym-alias-net,wagner}, or may
+through lawsuits or other
+means~\cite{nym-alias-net,wagner,helsingius,jap-backdoor,jap-pr}, or may
 attempt to surreptitiously obtain information about nym holders.
 
 We limit these effects of these attacks by greedily encrypting
-encrypt incoming messages and deleting encryption keys.% Nym holders do not
+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 as the bucket pool is generated,
@@ -559,7 +561,7 @@
 \subsubsection{Mix attacks.}
 Since we rely on mix networks, we must be concerned with attacks
 against them.
-Additionally, reply-block-based nym server systems require additional
+Furthermore, reply-block-based nym server systems require additional
 security properties that normal mix-net systems may not have~\cite{minx}.
 
 The Pynchon Gate uses mix-nets for forward message delivery only. Attacks
@@ -612,13 +614,12 @@
 holder~\cite{gd-thesis}.
 
 This attack relies primarily upon the ability to link one nym, $Alice_1$,
-with another nym, $Alice_2$, by sending a message encrypted to
-$Alice_1$'s to $Alice_2$'s address. The
-Pynchon Gate avoids this, though a similar social
-engineering attack may be performed if the nym holder is using a separate
-message encryption protocol such as PGP~\cite{rfc-2440}. More research
-needs to be done in the area of privacy-preserving human-computer
-interaction.
+with another nym, $Alice_2$, by sending a message encrypted to $Alice_1$'s
+to $Alice_2$'s address. The Pynchon Gate avoids this, though a similar
+social engineering attack may be performed if the nym holder is using a
+separate message encryption protocol such as PGP~\cite{rfc-2440}. More
+research needs to be done to improve the area of privacy-preserving
+human-computer interaction.
 
 
 \subsubsection{Usage pattern and intersection attacks.}
@@ -689,8 +690,8 @@
   nym33}.
 
 Recent work~\cite{statistical-disclosure,e2e-traffic} has studied an
-implementation of these intersection attacks called statistical
-Disclosure, where an attacker compares network behavior when Alice has sent
+implementation of these intersection attacks called \emph{statistical
+disclosure}, where an attacker compares network behavior when Alice has sent
 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}
@@ -743,15 +744,15 @@
 
 \section{Performance, Scalability and Optimizations}
 \label{sec:performance}
-In this protocol, the size of requests is proportional to the total number
-of messages and the size of responses is the bucket size. If one or the
-other of these values is large enough to cause scaling problems, then the
-collator can trade off bucket size for bit field size by doubling the
-bucket size, which halves the bit field size. With this approach, if the
-number of buckets becomes very large, then the message size rises
-proportionately to the square root of the number of buckets. This scales
-well, although it may necessitate multiple collators if the number of
-buckets gets extremely large.
+In this protocol, the size of requests is linearly proportional to the
+total number of messages and the size of responses is the bucket size. If
+one or the other of these values is large enough to cause scaling
+problems, then the collator can trade off bucket size for bit field size
+by doubling the bucket size, which halves the bit field size. With this
+approach, if the number of buckets becomes very large, then the message
+size rises proportionately to the square root of the number of buckets.
+This scales well, although it may necessitate multiple collators if the
+number of buckets gets extremely large.
 %As the collator presents a single target
 %point in a legal attack~\cite{nym-alias-net,wagner} or denial of
 %service scenario, it would be a good practice for multiple collators to
@@ -880,11 +881,11 @@
 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.
+Underhill uses a payload $P$ of size 28 KB, a reply block $r$ of size 2
+KB, and a packet size $M$ of 32 KB. 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
@@ -936,10 +937,10 @@
 \label{sec:conclusions}
 
 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.
+stronger anonymity assurance and greater robustness than other theorized
+or deployed high-latency pseudonymous message retrieval systems. Our
+system resists 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

Index: pynchon.bib
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.bib,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- pynchon.bib	18 Sep 2004 02:19:23 -0000	1.19
+++ pynchon.bib	20 Sep 2004 11:04:09 -0000	1.20
@@ -66,7 +66,7 @@
 }
 
 @inproceedings{freehaven-berk,
-  title = {The Free Haven Project: Distributed Anonymous Storage Service}, 
+  title = {The {Free Haven Project}: Distributed Anonymous Storage Service}, 
   author = {Roger Dingledine and Michael J. Freedman and David Molnar}, 
   booktitle = {Proceedings of Designing Privacy Enhancing Technologies: Workshop on Design
         Issues in Anonymity and Unobservability}, 

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