[or-cvs] clean up our references some more

Roger Dingledine arma at seul.org
Mon Jan 31 09:09:17 UTC 2005


Update of /home2/or/cvsroot/tor/doc/design-paper
In directory moria.mit.edu:/home2/arma/work/onion/cvs/tor/doc/design-paper

Modified Files:
	challenges.tex tor-design.bib 
Log Message:
clean up our references some more


Index: challenges.tex
===================================================================
RCS file: /home2/or/cvsroot/tor/doc/design-paper/challenges.tex,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -d -r1.27 -r1.28
--- challenges.tex	31 Jan 2005 08:34:38 -0000	1.27
+++ challenges.tex	31 Jan 2005 09:09:15 -0000	1.28
@@ -159,7 +159,7 @@
 
 Tor differs from other deployed systems for traffic analysis resistance
 in its security and flexibility.  Mix networks such as
-Mixmaster~\cite{mixmaster} or its successor Mixminion~\cite{minion-design}
+Mixmaster~\cite{mixmaster-spec} or its successor Mixminion~\cite{minion-design}
 gain the highest degrees of anonymity at the expense of introducing highly
 variable delays, thus making them unsuitable for applications such as web
 browsing that require quick response times.  Commercial single-hop
@@ -206,7 +206,7 @@
 Commercial single-hop proxies~\cite{anonymizer}, as well as unsecured
 open proxies around the Internet~\cite{open-proxies}, can provide good
 performance and some security against a weaker attacker. Dresden's Java
-Anon Proxy~\cite{jap} provides similar functionality to Tor but only
+Anon Proxy~\cite{web-mix} provides similar functionality to Tor but only
 handles web browsing rather than arbitrary TCP. Also, JAP's network
 topology uses cascades (fixed routes through the network); since without
 end-to-end padding it is just as vulnerable as Tor to end-to-end timing
@@ -219,8 +219,8 @@
 pseudonymous access rather than just anonymous access; but it had
 a different approach to sustainability (collecting money from users
 and paying ISPs to run servers), and has shut down due to financial
-load.  Finally, more scalable designs like Tarzan~\cite{tarzan} and
-MorphMix~\cite{morphmix} have been proposed in the literature, but
+load.  Finally, more scalable designs like Tarzan~\cite{tarzan:ccs02} and
+MorphMix~\cite{morphmix:fc04} have been proposed in the literature, but
 have not yet been fielded. We direct the interested reader to Section
 2 of~\cite{tor-design} for a more indepth review of related work.
 
@@ -531,7 +531,7 @@
 packet loss and out-of-order delivery. Freedom allegedly had one, but it was
 never publicly specified, and we believe it's likely vulnerable to tagging
 attacks \cite{tor-design}. Also, TLS over UDP is not implemented or even
-specified, though some early work has begun on that \cite{ben-tls-udp}.
+specified, though some early work has begun on that \cite{dtls}.
 \item \emph{We'll still need to tune network parameters}. Since the above
 encryption system will likely need sequence numbers and maybe more to do
 replay detection, handle duplicate frames, etc, we will be reimplementing
@@ -593,11 +593,11 @@
 fashion, it will increase the similarity of data stream timing
 signatures. By experimenting with the granularity of data chunks and
 of synchronization we can attempt once again to optimize for both
-usability and anonymity. Unlike in \cite{sync-batch}, it may be
+usability and anonymity. Unlike in \cite{sync-batching}, it may be
 impractical to synchronize on network batches by dropping chunks from
 a batch that arrive late at a given node---unless Tor moves away from
 stream processing to a more loss-tolerant processing of traffic (cf.\ 
-section~\ref{subsec:stream-vs-packet}). In other words, there would
+Section~\ref{subsec:stream-vs-packet}). In other words, there would
 probably be no direct attempt to synchronize on batches of data
 entering the Tor network at the same time. Rather, it is the link
 level batching that will add noise to the traffic patterns exiting the
@@ -918,6 +918,7 @@
 Geoff's stuff.
 
 \subsection{Location diversity and ISP-class adversaries}
+\label{subsec:routing-zones}
 
 Anonymity networks have long relied on diversity of node location for
 protection against attacks---typically an adversary who can observe a
@@ -930,7 +931,7 @@
 But how do we decide whether two nodes are in related locations?
 
 Feamster and Dingledine defined a \emph{location diversity} metric
-in \cite{routing-zones}, and began investigating a variant of location
+in \cite{feamster:wpes2004}, and began investigating a variant of location
 diversity based on the fact that the Internet is divided into thousands of
 independently operated networks called {\em autonomous systems} (ASes).
 The key insight from this paper is that while we typically think of a
@@ -954,8 +955,8 @@
 challenge to get an entire BGP routing table to each Tor client, or at
 least summarize it sufficiently. Without a local copy, clients won't be
 able to safely predict what ASes will be traversed on the various paths
-through the Tor network to the final destination. Tarzan~\cite{tarzan}
-and MorphMix~\cite{morphmix} suggest that we compare IP prefixes to
+through the Tor network to the final destination. Tarzan~\cite{tarzan:ccs02}
+and MorphMix~\cite{morphmix:fc04} suggest that we compare IP prefixes to
 determine location diversity; but the above paper showed that in practice
 many of the Mixmaster nodes that share a single AS have entirely different
 IP prefixes. When the network has scaled to thousands of nodes, does IP
@@ -1011,7 +1012,7 @@
 anonymizing networks again have an advantage here, in that we already
 have tens of thousands of separate IP addresses whose users might
 volunteer to provide this service since they've already installed and use
-the software for their own privacy~\cite{koepsell-wpes2004}. Because
+the software for their own privacy~\cite{koepsell:wpes2004}. Because
 the Tor protocol separates routing from network discovery (see Section
 \ref{do-we-discuss-this?}), volunteers could configure their Tor clients
 to generate server descriptors and send them to a special directory

Index: tor-design.bib
===================================================================
RCS file: /home2/or/cvsroot/tor/doc/design-paper/tor-design.bib,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -d -r1.6 -r1.7
--- tor-design.bib	29 Jan 2005 07:25:44 -0000	1.6
+++ tor-design.bib	31 Jan 2005 09:09:15 -0000	1.7
@@ -141,18 +141,18 @@
   title = {Timing Analysis in Low-Latency Mix-Based Systems},
   author = {Brian N. Levine and Michael K. Reiter and Chenxi Wang and Matthew Wright},
   booktitle = {Financial Cryptography},
-  year = {2004}, 
+  year = {2004},
   editor = {Ari Juels},
-  publisher = {Springer-Verlag, LNCS (forthcoming)}, 
+  publisher = {Springer-Verlag, LNCS (forthcoming)},
 }
 
 @inproceedings{morphmix:fc04,
   title = {Practical Anonymity for the Masses with MorphMix},
   author = {Marc Rennhard and Bernhard Plattner},
   booktitle = {Financial Cryptography},
-  year = {2004}, 
+  year = {2004},
   editor = {Ari Juels},
-  publisher = {Springer-Verlag, LNCS (forthcoming)}, 
+  publisher = {Springer-Verlag, LNCS (forthcoming)},
 }
 
 @inproceedings{eternity,
@@ -1116,6 +1116,56 @@
   note = {\url{http://students.cs.tamu.edu/xinwenfu/paper/PET04.pdf}},
 }
 
+ at InProceedings{danezis-pet2004,
+  author = "George Danezis",
+  title = "The Traffic Analysis of Continuous-Time Mixes",
+  booktitle= {Privacy Enhancing Technologies (PET 2004)},
+  editor = {David Martin and Andrei Serjantov},
+  month = {May},
+  year = {2004},
+  series = {LNCS},
+  note = {\url{http://www.cl.cam.ac.uk/users/gd216/cmm2.pdf}},
+}
+
+ at inproceedings{feamster:wpes2004,
+  title = {Location Diversity in Anonymity Networks},
+  author = {Nick Feamster and Roger Dingledine},
+  booktitle = {{Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2004)}},
+  year = {2004},
+  month = {October},
+  address = {Washington, DC, USA},
+  note = {\url{http://freehaven.net/doc/routing-zones/routing-zones.ps}},
+}
+
+ at inproceedings{koepsell:wpes2004,
+  title = {How to Achieve Blocking Resistance for Existing Systems Enabling Anonymous Web Surfing},
+  author = {Stefan K\"opsell and Ulf Hilling},
+  booktitle = {{Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2004)}},
+  year = {2004},
+  month = {October},
+  address = {Washington, DC, USA},
+  note = {\url{http://freehaven.net/anonbib/papers/p103-koepsell.pdf}},
+}
+
+ at inproceedings{sync-batching,
+  title = {Synchronous Batching: From Cascades to Free Routes},
+  author = {Roger Dingledine and Vitaly Shmatikov and Paul Syverson},
+  booktitle = {Proceedings of Privacy Enhancing Technologies workshop (PET 2004)},
+  year = {2004},
+  month = {May},
+  series = {LNCS},
+  note = {\url{http://freehaven.net/doc/sync-batching/sync-batching.pdf}},
+}
+
+ at Misc{dtls,
+   author =      {E. Rescorla and N. Modadugu},
+   title =       {{Datagram Transport Layer Security}},
+   howpublished = {IETF Draft},
+   month =       {December},
+   year =        {2003},
+   note =        {\url{http://www.ietf.org/internet-drafts/draft-rescorla-dtls-02.txt}},
+}
+
 %%% Local Variables: 
 %%% mode: latex
 %%% TeX-master: "tor-design"



More information about the tor-commits mailing list