[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