Update of /home/freehaven/cvsroot/doc/pynchon-gate
In directory moria:/tmp/cvs-serv13328
Modified Files:
pynchon.tex
Log Message:
a round of small revisions.
Index: pynchon.tex
===================================================================
RCS file: /home/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.74
retrieving revision 1.75
diff -u -d -r1.74 -r1.75
--- pynchon.tex 2 Sep 2005 02:53:02 -0000 1.74
+++ pynchon.tex 2 Sep 2005 07:22:20 -0000 1.75
@@ -69,7 +69,7 @@
\maketitle
\begin{abstract}
-We argue for the Pynchon Gate, a practical pseudonymous message retrieval
+We describe the Pynchon Gate, a practical pseudonymous message retrieval
system. Our design uses a simple distributed-trust private information
retrieval protocol to prevent adversaries from linking recipients to their
pseudonyms, even when some of the infrastructure has been compromised. This
@@ -101,12 +101,12 @@
%%%%%%%%%%%%%%%%%%%%
\section{Introduction}
-Pseudonymous messaging services seek to provide users with a way to send
+Pseudonymous messaging services allow users to send
messages that originate at a pseudonymous address (or ``nym'') unlinked to
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
+These systems can be used for users
+to communicate without revealing their identities, or can be used as a
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
@@ -133,19 +133,20 @@
\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
-from a global eavesdropper for as long as possible; should hinder active
-attackers who can delay, delete, or introduce traffic; and should resist an
+for forward message anonymity. Thus, we should try to protect users'
+identities
+from a global eavesdropper for as long as possible; to hinder active
+attackers who can delay, delete, or introduce traffic; and to resist an
attacker who has compromised some (but not all) of the servers on the
network.
In order to provide security, however, we must ensure that the system is
-{\it deployable} and {\it usable}---since anonymity and pseudonymity systems
+{\it deployable} and {\it usable}: since anonymity and pseudonymity systems
hide users among each other, fewer users means less
-protection~\cite{econymics}. This implies that we should handle
-node failure without loss of mail; that we must not require more bandwidth
+protection~\cite{econymics}. Thus, we should handle
+node failure without loss of mail; we must not require more bandwidth
than volunteer servers can provide or users are willing to use; and
-that we should not require a complicated interface.
+we should not require a complicated interface.
\subsubsection{In this paper.}
We begin in Section~\ref{sec:background} with a discussion of related work,
@@ -168,7 +169,7 @@
\subsection{Related Work}
\label{subsec:related-work}
-Below we discuss existing designs for pseudonymous message delivery.
+First, we discuss existing designs for pseudonymous message delivery.
Many assume the existence of a ``forward'' anonymous channel that a sender
can use to send a message to a known recipient while preventing the
recipient, the infrastructure, and any attackers from knowing who is
@@ -224,7 +225,6 @@
blocks, and prevent replay attacks~\cite{replay}.
\subsubsection{Single-use reply blocks.}
-
While the Type II system does not support anonymous
reply blocks, the Type III (Mixminion) system introduces single-use reply
blocks
@@ -239,16 +239,16 @@
set, and recent
work has been done by Danezis and Laurie on attack-resistant anonymous
packet formats suitable for reply messages~\cite{minx}. However, since
-reply blocks are still being used, reliability issues remain. (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
+reply blocks are still used, reliability issues remain: if
+any given node in the pre-selected SURB's path is defunct during the interval
+in which the mail is
+to be delivered, the mail is 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 reliably determine who is talking to
whom~\cite{statistical-disclosure}.
\subsubsection {Network-level client anonymity.}
-
The ZKS Freedom Network~\cite{freedom2-arch} provided anonymous access
to a POP3 server~\cite{freedom2-mail}, enabling its users to maintain
pseudonyms using standard email protocols. Freedom was discontinued due to
@@ -259,20 +259,19 @@
in much the same fashion; unfortunately, they face the same
barriers to widespread deployment~\cite{fiveyearslater}. Attempts to address
the practical barriers to deployment of low-latency anonymity systems have resulted
-in systems which are at greater risk to traffic analysis methods such as end-to-end
+in designs which are at greater risk to traffic analysis methods such as end-to-end
timing attacks~\cite{danezis-pet2004,gd-thesis,torta05,mixmaster-reliable} It is possible
that such a low-latency system may be developed which is both secure against
end-to-end analysis and cost-effective to operate, but no such system has yet
been proven feasible.
\subsubsection{Network-level server anonymity.}
-
-The second generation implementation of Onion Routing, Tor~\cite
-{tor-design}, implements rendezvous points~\cite {ian-thesis} that allow
+The second generation implementation of Onion Routing, Tor~\cite{tor-design},
+implements rendezvous points~\cite{ian-thesis} that allow
users to offer location-hidden services. A user wishing to anonymously
-receive messages could use this to receive mail at a hidden location:
-Messages would be delivered to the server over the Onion Routing network,
-and successful delivery would not require the sender to know the IP
+receive messages can use this to receive mail at a hidden location:
+messages are delivered to the server over the Onion Routing network,
+and successful delivery does not require the sender to know the IP
address of the destination server.
Rendezvous points offer an alternative method of leveraging network-level
@@ -280,7 +279,6 @@
the previously mentioned concerns with these anonymity systems.
\subsubsection{Re-encryption mixes.}
-
Re-encryption mixes~\cite{universal} aim to improve the reliability of
anonymous message systems. Recent work has shown that re-encryption mixes
can be used to facilitate anonymous message replies~\cite
@@ -293,7 +291,6 @@
time the message is retrieved.
\subsubsection{Broadcast messages and dead-drops.}
-
Chaum discusses a traffic-analysis prevention method in which all reply
mail in the anonymous mail system is sent to all possible recipients. A
less invasive optimization has already been implemented in the form of
@@ -799,7 +796,7 @@
To examine this effect, we ran a version of the attack simulations
described in~\cite{e2e-traffic}, assuming a single target pseudonym and $N$
non-target pseudonyms providing cover. In order to make the attack
-as difficult as possible (and thus establish an upper bound for security), we
+as difficult as possible (and thus establish an upper bound on security), we
assume that users behave identically: they receive messages with equal
probability according to independent geometric distributions in each unit of
time (receiving no messages with probability $1-P_M$); they use
@@ -858,7 +855,7 @@
distribution nodes for architecture or resource reasons, their anonymity
sets would remain separate.)
-The PIR algorithm suggested in this paper does
+The PIR algorithm in this paper does
not have optimal asymptotic performance, especially in bandwidth.
We present it nonetheless because it
is easy to explain, implement, and analyze, and offers sufficient
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe freehaven-cvs in the body. http://freehaven.net/