note = {\url{http://freehaven.net/doc/fc03/econymics.pdf}},
}
+@inproceedings{eternity,
+ title = {The Eternity Service},
+ author = {Ross Anderson},
+ booktitle = {Proceedings of Pragocrypt '96},
+ year = {1996},
+ note = {\url{http://www.cl.cam.ac.uk/users/rja14/eternity/eternity.html}},
+}
+
@inproceedings{minion-design,
title = {Mixminion: Design of a Type {III} Anonymous Remailer Protocol},
note = {\url{http://www.onion-router.net/Publications/WDIAU-2000.ps.gz}},
}
+@Inproceedings{freenet-pets00,
+ title = {Freenet: A Distributed Anonymous Information Storage
+ and Retrieval System},
+ author = {Ian Clarke and Oskar Sandberg and Brandon Wiley and
+ Theodore W. Hong},
+ booktitle = {Designing Privacy Enhancing Technologies: Workshop
+ on Design Issue in Anonymity and Unobservability},
+ year = 2000,
+ month = {July},
+ pages = {46--66},
+ editor = {H. Federrath},
+ publisher = {Springer-Verlag, LNCS 2009},
+ note = {\url{http://citeseer.nj.nec.com/clarke00freenet.html}},
+}
+
+
@InProceedings{or-ih96,
author = {David M. Goldschlag and Michael G. Reed and Paul
F. Syverson},
note = {\newline \url{http://www.scs.cs.nyu.edu/~dm/}},
}
+
+
+@InProceedings{tangler,
+ author = {Marc Waldman and David Mazi\`{e}res},
+ title = {Tanger: A Censorship-Resistant Publishing System
+ Based on Document Entanglements},
+ booktitle = {$8^{th}$ ACM Conference on Computer and
+ Communications Security (CCS-8)},
+ pages = {86--135},
+ year = 2001,
+ publisher = {ACM Press},
+ note = {\url{http://www.scs.cs.nyu.edu/~dm/}}
+}
+
@misc{neochaum,
author = {Tim May},
title = {Payment mixes for anonymity},
@inproceedings{SS03,
title = {Passive Attack Analysis for Connection-Based Anonymity Systems},
author = {Andrei Serjantov and Peter Sewell},
- booktitle = {Proceedings of ESORICS 2003},
+ booktitle = {Computer Security -- ESORICS 2003},
+ publisher = {Springer-Verlag, LNCS (forthcoming)},
year = {2003},
month = {October},
+ note = {\url{http://www.cl.cam.ac.uk/users/aas23/papers_aas/conn_sys.ps}},
}
@Article{raghavan87randomized,
month = {December},
}
+@Article{taz,
+ author = {Ian Goldberg and David Wagner},
+ title = {TAZ Servers and the Rewebber Network: Enabling
+ Anonymous Publishing on the World Wide Web},
+ journal = {First Monday},
+ year = 1998,
+ volume = 3,
+ number = 4,
+ month = {August},
+ note = {\url{http://www.firstmonday.dk/issues/issue3_4/goldberg/}}
+}
+
@inproceedings{wright02,
title = {An Analysis of the Degradation of Anonymous Protocols},
author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields},
@inproceedings{wright03,
title = {Defending Anonymous Communication Against Passive Logging Attacks},
author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields},
- booktitle = {Proceedings of the 2003 IEEE Symposium on Security and Privacy},
+ booktitle = {2003 IEEE Symposium on Security and Privacy},
+ pages= {28--41}
year = {2003},
month = {May},
+ publisher = {IEEE CS},
}
%%% Local Variables:
different networks to succeed'' \cite{crowds-tissec}.
-[XXX I'm considering the subsection as ended here for now. I'm leaving the
-following notes in case we want to revisit any of them. -PS]
+Many systems have been designed for censorship resistant publishing.
+The first of these was the Eternity Service \cite{eternity}. Since
+then, there have been many alternatives and refinements, of which we note
+but a few
+\cite{eternity,gap-pets03,freenet-pets00,freehaven-berk,publius,tangler,taz}.
+From the first, traffic analysis resistant communication has been
+recognized as an important element of censorship resistance because of
+the relation between the ability to censor material and the ability to
+find its distribution source.
+
+Tor is not primarily for censorship resistance but for anonymous
+communication. However, Tor's rendezvous points, which enable
+connections between mutually anonymous entities, also facilitate
+connections to hidden servers. These building blocks to censorship
+resistance and other capabilities are described in
+Section~\ref{sec:rendezvous}.
-There are also many systems which are intended for anonymous
-and/or censorship resistant file sharing. [XXX Should we list all these
-or just say it's out of scope for the paper?
-eternity, gnunet, freenet, freehaven, publius, tangler, taz/rewebber]
+[XXX I'm considering the subsection as ended here for now. I'm leaving the
+following notes in case we want to revisit any of them. -PS]
Channel-based anonymizing systems also differ in their use of dummy traffic.
to it including refusing them entirely, intentionally modifying what
it sends and at what rate, and selectively closing them. Also a
special case of the disrupter.
-\item[Key breaker:] can break the longterm private decryption key of a
- Tor-node.
+\item[Key breaker:] can break the key used to encrypt connection
+ initiation requests sent to a Tor-node.
% Er, there are no long-term private decryption keys. They have
% long-term private signing keys, and medium-term onion (decryption)
% keys. Plus short-term link keys. Should we lump them together or
% separate them out? -RD
-\item[Compromised Tor-node:] can arbitrarily manipulate the connections
- under its control, as well as creating new connections (that pass
- through itself).
+%
+% Hmmm, I was talking about the keys used to encrypt the onion skin
+% that contains the public DH key from the initiator. Is that what you
+% mean by medium-term onion key? (``Onion key'' used to mean the
+% session keys distributed in the onion, back when there were onions.)
+% Also, why are link keys short-term? By link keys I assume you mean
+% keys that neighbor nodes use to superencrypt all the stuff they send
+% to each other on a link. Did you mean the session keys? I had been
+% calling session keys short-term and everything else long-term. I
+% know I was being sloppy. (I _have_ written papers formalizing
+% concepts of relative freshness.) But, there's some questions lurking
+% here. First up, I don't see why the onion-skin encryption key should
+% be any shorter term than the signature key in terms of threat
+% resistance. I understand that how we update onion-skin encryption
+% keys makes them depend on the signature keys. But, this is not the
+% basis on which we should be deciding about key rotation. Another
+% question is whether we want to bother with someone who breaks a
+% signature key as a particular adversary. He should be able to do
+% nearly the same as a compromised tor-node, although they're not the
+% same. I reworded above, I'm thinking we should leave other concerns
+% for later. -PS
+
+
+\item[Compromised Tor-node:] can arbitrarily manipulate the
+ connections under its control, as well as creating new connections
+ (that pass through itself).
\end{description}
projects / thirdparty / tor.git / commitdiff
