[freehaven-cvs] Fixed some typos.

[rabbi@seul.org]

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

Modified Files:
	pynchon.tex 
Log Message:
Fixed some typos.


Index: pynchon.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- pynchon.tex	26 Jan 2004 08:44:05 -0000	1.1
+++ pynchon.tex	26 Jan 2004 09:26:49 -0000	1.2
@@ -49,7 +49,7 @@
 \section{Introduction}
 
 We propose a novel way of using private information retrieval
-(PIR)\cite{pir} primitives as the basis of a secure, fault-tolerant method
+(PIR)~\cite{pir} primitives as the basis of a secure, fault-tolerant method
 of anonymous mail retrieval.
 
 The system we propose consists of a number of components. The \emph{nym
@@ -78,38 +78,38 @@
 
 \subsubsection{Reply-blocks and return addresses}
 
- Chaum\cite{chaum-mix} describes a method of using \emph{return addresses}
+Chaum~\cite{chaum-mix} describes a method of using \emph{return addresses}
 with forward-secure mix-nets. However, the system relies upon all selected
 component nodes of the mix being active in order for mail to be delivered.
 In practice, 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
+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 such as
-omega.c2.net\cite{} and nym.alias.net \cite{} implemented the concept of a
+omega.c2.net~\cite{} and nym.alias.net~\cite{} implemented the concept of a
 central reply-block repository, allowing pseudonym-holders to receive
 messages delivered to a traditional email address. Unfortunately,
 reply-block systems based on the first generation implementation of
-ChaumÕs mix-nets (Type I remailers) allow multiple-use reply blocks.
+Chaum's mix-nets (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
+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 and
 Type III systems do not permit multiple-use reply blocks, and contain
-replay-attack protection mechanisms.\cite{replay}
+replay-attack protection mechanisms~\cite{replay}.
 
 \subsubsection{Single-use reply blocks}
 
 While the Type II system does not have any means of support for anonymous
-reply blocks, the Type III system\cite{mixminion} introduces single-use
-reply blocks (SURBs)\cite{surb} as a means of avoiding the replay attack
+reply blocks, the Type III system~\cite{mixminion} introduces single-use
+reply blocks (SURBs)~\cite{surb} as a means of avoiding the replay attack
 issues. Mixminion requires the 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
+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
@@ -118,30 +118,30 @@
 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
+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}
+correlation~\cite{statistical-disclosure}.
 
 
 \subsubsection {Network-level client anonymity}
 
-ZKS Freedom mail. The Freedom Network\cite{freedom2-arch} provided
-anonymous IP access to a POP3 server\cite{freedom2-mail}, enabling its
+ZKS Freedom mail. The 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
+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
+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}

+mixes, and are more susceptible to traffic analysis attacks~\cite
+{danezis-traffic-analysis}.
 
 \subsubsection{Network-level server anonymity}
 
-The second generation implementation of Onion Routing\cite {tor-design}
-implements the concept of rendezvous points,~\cite {ian-thesis} which
+The second generation implementation of Onion Routing~\cite {tor-design}
+implements the concept of rendezvous points~\cite {ian-thesis}, which
 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
@@ -153,26 +153,28 @@
 
 \subsubsection{Re-encryption mixes}
 
-Re-encryption mixes \cite {universal} aim to improve the reliability of
+Re-encryption mixes~\cite {universal} aim to improve the reliability of
 anonymous information retrieval. While they do improve on the robustness
 of simple reply blocks, reliability problems are still possible.
 Re-encryption mixes require that the security vs. reliability tradeoffs be
 made by the sender at the time that the message is sent. A more desirable
 property 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.
+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.
 
 \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
 more friendly optimization has already been attempted in the form of
-Usenet mail drops:\cite{aam} an anonymous remailer can be instructed to
+Usenet mail drops~\cite{aam}: an anonymous remailer can be instructed to
 deliver mail to a newsgroup, rather than to an email recipient. Such mail
 could be encrypted with a recipient's private key, and left for her to
 collect from the newsgroup. If all users of the system are using the same
@@ -183,15 +185,15 @@
 reply-block based system as the drop location could be agreed upon out of
 band.
 
-This "send everything everywhere" approach suffers massive scalability
+This ``send everything everywhere'' approach suffers massive scalability
 problems. As the number of users in the system increases (and thus, the
 anonymity strength of the system also increases) the resource requirements
-become prohibitive. Users will be encouraged to "cheat," and only download
+become prohibitive. Users will be encouraged to ``cheat,'' and only download
 sections of the newsgroup that they are sure contain their messages, or
 not download on days that they don't expect messages. This allows an
 attacker to gather information about messages in which an individual has
 interest, and provides a way to attack the security of the
-system.\cite{harmful}
+system~\cite{harmful}.
 
 
 \section{Design Rationale}
@@ -206,11 +208,11 @@
 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, the adversary cannot
+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,
-reliability, and security of the "send everything everywhere" method,
+reliability, and security of the ``send everything everywhere'' method,
 while bringing the system back into the realm of feasibility for users
 with limited resources. While using the information theory-based PIR
 primitive, we are able to avoid the use of cryptography wherever possible.
@@ -228,7 +230,7 @@
 The public-facing side of The Pynchon Gate consists a nym server which
 sends and receives pseudonymous email. The nym server itself provides no
 sender anonymity; rather, it relies on existing mix
-networks\cite{mixmaster-spec}\cite{mixminion} for forward message
+networks~\cite{mixmaster-spec}~\cite{mixminion} for forward message
 anonymity. The nym server is visible to external email correspondents, and
 receives messages for the nym owners at their specified email
 addresses.
@@ -271,7 +273,7 @@
 
 The entire set of buckets is retrieved from the collator by
 multiple \emph{distributor nodes}.\footnote{This should be accomplished by
-using a bandwidth-sparing protocol such as BitTorrent.\cite{bittorrent}}
+using a bandwidth-sparing protocol such as BitTorrent~\cite{bittorrent}.}
 Distributors append to each bucket the path from that bucket to the hash
 tree root. These distributors communicate to the client application using
 the \emph{Pynchon Gate Client Protocol}.
@@ -291,7 +293,7 @@
 stream cipher instead of the full bit field. The distributor will use the
 stream cipher as a pseudo-random number generator to generate the full bit
 field. This reduces the size of the request from linear on the number of
-buckets to fixed.\cite{prng-back}}
+buckets to fixed~\cite{prng-back}.}
 
 For the final distributor, the client takes the xor of all of the other
 bit fields that it sent\footnote{Stream cipher output generated by the
@@ -380,7 +382,7 @@
 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} or denial of service scenario,
+point in a legal attack~\cite{nym-alias-net} or denial of service scenario,
 it would be a good practice for multiple collators to exist.\footnote{Note
 that while different collators may share the same distribution nodes for
 architecture or resource reasons, the anonymity sets would remain
@@ -398,7 +400,7 @@
 the potential effectiveness of attacks in which a distributor sends back
 garbled data to see if the client accepts it is unclear. Also, private
 information retrieval primitives are an area of active research with
-ongoing improvements taking place\cite{beimel-barrier}, so waiting to
+ongoing improvements taking place~\cite{beimel-barrier}, so waiting to
 implement a more sophisticated algorithm will likely result in greater
 resource savings once the implementation occurs.
 
@@ -458,7 +460,7 @@
 
 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}.
+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

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