[freehaven-cvs] Misc edits.

[rabbi@seul.org]

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

Modified Files:
	pynchon.tex 
Log Message:
Misc edits.


Index: pynchon.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.33
retrieving revision 1.34
diff -u -d -r1.33 -r1.34
--- pynchon.tex	17 Sep 2004 15:31:55 -0000	1.33
+++ pynchon.tex	17 Sep 2004 18:22:29 -0000	1.34
@@ -178,7 +178,7 @@
 remailers~\cite{hal-remailer}), such as {\tt
 alpha.c2.net}~\cite{alpha-faq} and {\tt
 nym.alias.net}~\cite{nym-alias-net}, implemented a central
-reply-block repository which allowed pseudonym-holders to receive messages
+reply-block repository which allowed pseudonym holders to receive messages
 delivered to a traditional 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}
@@ -220,7 +220,7 @@
 Pipenet~\cite{pipenet}, Onion Routing~\cite{goldschlag96}, the Java Anon
 Proxy~\cite{jap}, or Tor~\cite{tor-design}, could be used
 in much the same fashion; unfortunately, they also suffer the same
-barriers to deployment~\cite{fiveyearslater}.% The Java Anonymous
+barriers to deployment~\cite{fiveyearslater}. % The Java Anonymous
 %Proxy~\cite{jap} has had greater adoption, but has suffered an anonymity
 %compromise~\cite{jap-backdoor,jap-pr}.
 Low-latency anonymity systems such as these are also far more susceptible to
@@ -253,26 +253,6 @@
 would be to allow the recipient to make security determinations at the
 time the message is retrieved.
 
-%Mix-nets inherently rely upon cryptographic primitives for their security.
-%While the cryptographic primitives utilized in traditional Chaumian
-%mix-nets are fairly well understood, the additional primitives in
-%re-encryption mixes have received less rigorous analysis. Analysis of
-%cryptographic primitives has a long history of being fraught with peril,
-%and in many cases flaws remained unnoticed until years after a system
-%first achieved wide deployment.\footnote{Re-encryption mixes rely on the
-%ElGamal cryptosystem~\cite{elgamal}, aspects of which have been discovered
-%to contain flaws~\cite{bleichenbacher,nguyen} that have
-%significantly affected deployed cryptographic
-%applications~\cite{pgp5-elgamal,gpg-compromised}. While these
-%particular flaws are related to ElGamal signature schemes rather than the
-%encryption techniques used by re-encryption mixes, general concerns about
-%implementation security of the ElGamal cryptosystem remain.}
-%
-%% I think the thing above is kinda FUDdy -- the entire anonymity field is
-%% less well analyzed than the discrete log problem. (NM)
-%%
-%% I agree we should take this out. (LS)
-
 \subsubsection{Broadcast messages and dead-drops.}
 Chaum discusses a traffic-analysis prevention method wherein all reply
 mail in the anonymous mail system is sent to all possible recipients. A
@@ -311,7 +291,7 @@
 \subsubsection{Legal and hacking attacks.}
  Attackers may attempt to coerce the operators of pseudonymity systems
 through lawsuits or other means, or may attempt to surreptitiously obtain
-information about nym-holders. Systems should be designed so that such
+information about nym holders. Systems should be designed so that such
 information cannot be obtained.
 
 \subsubsection{Mix attacks.} 
@@ -328,11 +308,11 @@
 \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.
+nym holder.
 
 \subsubsection{{\it Who am I?} attack.} 
 An attacker may send messages intended for nym Alice to nym Bob instead,
-to confirm that Alice and Bob are the same nym-holder~\cite{gd-thesis}.
+to confirm that Alice and Bob are the same nym holder~\cite{gd-thesis}.
 
 \subsubsection{Usage pattern and intersection attacks.}
 
@@ -348,10 +328,8 @@
 system, an attacker could disable certain mixes, and observe which nyms
 ceased receiving traffic. If the nym holder has a fixed-route reply block,
 this would enable the attacker to identify the mixes used in the
-nym-holder's reply-block path, and increase his chances of successfully
-linking the nym with the nym-holder's true name.
-
-\subsubsection{Statistical-disclosure attacks.}
+nym holder's reply-block path, and increase his chances of successfully
+linking the nym with the nym holder's true name.
 
 \subsection{Statistical disclosure against reply-block-based nym servers}
 \label{subsec:disclosure}
@@ -429,15 +407,19 @@
 the security properties of PIR is trivial in comparison to many
 cryptographic primitives.
 
-
-\section{Component Details}
-% Fold this into the previous section
-
 The Pynchon Gate consists of a number of logical components, some of which
 may or may not coexist on the same network device or as part of the same
 application.
 
-% XXX Figure 1.
+\begin{figure}
+\begin{center}
+\includegraphics[width=7cm, height=3cm]{PynFig1.eps}
+
+\caption{The Pynchon Gate Architecture}
+\label{pyn-arch}
+\end{center}
+\end{figure}
+
 
 \subsection{The Nym Server}
 
@@ -476,10 +458,8 @@
 addressed at the collator to an opaque id which remains unchanged for the
 nym. The actual messages include the iteration number of the dynamic key
 in the clear, and the messages for the nym user are encrypted and MAC'd
-using that iteration of the dynamic key.
-
-%XXXX Integrate me into the text
-  $\UserID{}[i] = H(S[i] | \mbox{\tt "USER ID"})$
+using that iteration of the dynamic key: 
+$\UserID{}[i] = H(S[i] | \mbox{\tt "USER ID"})$
 
 Dynamic key rotation allows us to achieve forward secrecy. Without dynamic
 key rotation it would be trivial for an attacker to archive all data sent
@@ -497,9 +477,6 @@
 and discard $\SUBKEY(j,i)$.  After each cycle, the nymserver should discard
 the last $\SUBKEY(j,i)$, and $\UserID{}[i]$.
 
-% XXXX Clean up the above. I lifted this from the spec -- it should be
-% made pretty.  --Len.
-
 \subsection{The Collator}
 
 Messages for nym owners are passed to the collator component.\footnote{The
@@ -690,9 +667,9 @@
 consideration for serious anonymity solutions~\cite{back01}.
 
 \subsection{Comparing Pynchon Gate to other systems}
-XXXX write this.  Describe the other systems:
-  Type I nymservers, aam, underhill, underhill with full padding,
-   pynchon gate.
+%XXXX write this.  Describe the other systems:
+%  Type I nymservers, aam, underhill, underhill with full padding,
+%   pynchon gate. (Is this necessary? We discuss these earlier.)
 
 XXXX Describe meaning of letters.  Describe that ``infrastructure'' is a
 mixnet for type I/III, and is distributors for pynchon, and is nntp servers
@@ -747,32 +724,32 @@
 %XXXX Merge into conclusion, where we evaluate our success.
 %XXXX I don't mind chopping this whole section out if we need to. -LS.
 
-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 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
-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. 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.
+%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 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
+%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. 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.
 
 \section{Conclusions}
 \label{sec:conclusions}
@@ -783,11 +760,10 @@
 This system, when properly utilized, resists traffic analysis better than
 existing systems, and offers convenient scalability options.
 
-We have made some initial suggestions for a basic client architecture
-which can facilitate an optimally unobtrusive user interface. Much work
-remains in the field of effective user interface design for privacy and
-anonymity systems, particularly when the privacy component is viewed by
-the user as optional~\cite {sassaman-lisa}. 
+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
+design for privacy and anonymity systems, particularly when the privacy
+component is viewed by the user as optional~\cite {sassaman-lisa}.
 
 %As it is our intent to build and
 %deploy a system based on the principles of The Pynchon Gate, it is

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