[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] Added the rough draft. I think all the content is he...
Update of /home2/freehaven/cvsroot/doc/pynchon-gate
In directory moria.mit.edu:/tmp/cvs-serv12077
Added Files:
pynchon.tex pynchon.bib llncs.cls
Log Message:
Added the rough draft. I think all the content is here. I'll proof-read
and fix type-settings tomorrow. Yay, last minute submissions.
--- NEW FILE: pynchon.tex ---
\documentclass[runningheads]{llncs}
\usepackage{url}
\usepackage{graphics}
\usepackage{amsmath}
\usepackage{subfigure}
\usepackage{epsfig}
\setcounter{page}{1}
\begin{document}
\title{The Pynchon Gate}
\subtitle{A Secure Method of Pseudonymous Mail Retrieval}
\author{Len Sassaman\inst{1} \and Bram Cohen\inst{2}}
\institute{Anonymizer, Inc., \\
5694 Mission Center Road, Suite 426, \\
San Diego, CA 92108-4380 USA. \\
\email{rabbi@abditum.com}
\and
BitTorrent, \\
2018 Shattuck Avenue, Suite 124, \\
Berkeley, CA 94704 USA. \\
\email{bram@bitconjurer.org}
}
\maketitle
\begin{abstract}
We present The Pynchon Gate, a pseudonymous message retrieval system. The
Pynchon Gate is based upon Private Information Retrieval, an information
theory primitive that enables us to address many of the known problems
with existing pseudonymous communication systems. We propose a system
where the user retrieves a subset of the collection of all messages in
such a way that the user leaks no information about which messages he is
retrieving, and a global observer is unable to correlate sender behavior
with recipient usage patterns. We introduce a more stable architecture for
pseudonymous mail systems and analyze its strengths and weaknesses as
compared to existing systems. We discuss security concerns raised by this
new model for pseudonymity, and propose solutions. We describe the
architecture in a form sufficient for implementation, including
countermeasures to basic attacks against the system.
\end{abstract}
\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
of anonymous mail retrieval.
The system we propose consists of a number of components. The \emph{nym
server} component interfaces with the email network; it delivers mail to
external email addresses from authenticated nym owners, receives mail for
nym accounts, and processes administrative \emph{control messages} related
to individual nym accounts. Incoming email is passed from the nym server
to the \emph{collator} component, which prepares message batches to be
replicated to the \emph{distributor} components. The distributor
components, through the use of the \emph{private information retrieval
protocol}, allow nym owners to receive mail from the nym server while
maintaining unlinkability between a message and its recipient.
\subsection{Goals}
While sender-anonymity systems such as Mixmaster have been available for
public use for nearly a decade, there remains a need for a secure, robust
system which will allow users to receive mail anonymously. The system
should be of equivalent or greater security than the state of the art for
forward message anonymity; should gracefully handle node failure without
loss of mail; should be resistant to attack from rogue nodes; and should
not require a complicated interface or special knowledge in order to be
effectively employed by the end user.
\subsection{Related Work}
\subsubsection{Reply-blocks and 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
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
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.
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
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}
\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
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
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
anonymity set, which is a significant security improvement over Type I.
However, since reply blocks are still being used, the reliability issues
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
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}
\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
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
in much the same fashion; unfortunately, they also suffer the same
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}
\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
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
the onion routing network, and successful delivery would not require the
sender to know the IP address of the destination server.
Rendezvous
points offer an alternative method of leveraging network-level anonymity
systems for anonymous mail receipt; however, they do not address the
previously mentioned concerns with these anonymity systems.
\subsubsection{Re-encryption mixes}
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.
\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
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
newsgroup, and are behaving in an identical manner (for instance, by
downloading the entire set of newsgroup messages daily), this will address
the possible statistical attacks on direct mail delivery of reply messages
to individual email addresses, and also removes the necessity for a
reply-block based system as the drop location could be agreed upon out of
band.
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
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}
\section{Design Rationale}
The Pynchon Gate is a network of servers that provide anonymous message
retrieval capabilities. The servers receive messages for many different
pseudonym accounts via email \footnote {The servers could also receive
messages through any suitable medium for message transfer} and pass these
messages to each independently-operated distributor node in the network.
Through the use of a client which can communicate with the distributor
nodes, the owner of a given pseudonym is able to make a series of requests
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
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,
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.
A basic analysis of the security properties of PIR is trivial in
comparison to many cryptographic primitives.
\section{Component Details}
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.
\subsection{The Nym Server}
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
anonymity. The nym server is visible to external email correspondents, and
receives messages for the nym owners at their specified email
addresses.
Nym servers manage email accounts for pseudonyms (\emph{nym accounts}).
The account creation process establishes a \emph{fixed shared secret}
shared between the nym server and the nym owner for use in encrypting and
authenticating control messages related to the nym email address.
Similarly, the account creation process establishes a \emph{dynamic shared
secret}, used to encrypt messages to the nym owner. To achieve forward
secrecy, each time the dynamic shared secret is used, it is then changed
to the hash of its current value.
Messages sent from the nym owner to the nym server include a simple MAC to
authenticate them; they are encrypted at the anonymous mail forwarding
system layer. Messages sent from the nym server to the nym owner are
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.
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
to distributors, and the at some later time obtain the nym's collator
address and key from the nym server, (possibly by using a legal attack).
The attacker would then be able to read all messages that nym has ever
received.
\subsection{The Collator}
Messages for nym owners are passed to the collator component\footnote{The
collator component typically resides on the same physical server as the
nym server.} The collator component organizes all messages into a tree
structure, with messages sorted by publicly viewable identifiers derived
from the dynamic shared secrets. Nodes in the tree are organized into
fixed-size \emph{buckets}. The collator then publishes metadata about the
tree as a whole in a widely available manner.
\subsection{The Distributor Nodes}
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}}
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}.
\subsection{The Pynchon Gate Client}
The \emph{Pynchon Gate Client} application resides on the nym owner's
local computer, and periodically retrieves messages from the distributor
nodes using the Pynchon Gate Client Protocol.
The Pynchon Gate Client Protocol is as follows: The client application
sends a random-looking bit field to the distributor. This bit field has a
length equal to the number of buckets. The distributor performs a linear
scan across all buckets, and xors the buckets whose positions have a
corresponding 1 in the bit field. The result of this xor is then returned
to the client.\footnote{As an optimization, a client may send a seed to a
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}}
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
seeds it sent could also be used.} and flips a single bit corresponding to
the bucket to be retrieved.\footnote{The bandwidth conservation
optimization does not apply at this step.}
The client xors the results returned by all the distributors and verifies
that the path to the hash root appended by the distributors is correct. At
this point, the client has received the bucket that it requested. This
process is repeated until the hash tree is traversed to a leaf node, which
will contain the desired message or messages.
In order to protect against usage pattern attacks, the size of the
response to all message requests for an individual client must be a fixed
size. If the number of messages contained in the system is too great to
return in this normalized manner, a notation must be included in the data
from the collator indicating that there are further messages waiting as
well as the size of the pending data to be delivered. The client may then
send administrative requests via an anonymous email message to the
collator indicating whether the pending messages should be delivered or
discarded.
\section{Security Concerns}
As with any anonymity system, care must be taken at all steps to prevent
possible attacks on the effective anonymity provided.
In order to protect against usage pattern attacks, it is imperative that
the tree depth be the same for all leaf nodes.
The collator is responsible for publishing tree metadata. This metadata
includes the depth of the tree, the individual size of each bucket, the
total number of buckets, and a hash tree root which can be used to verify
the integrity of any bucket individually. Clients must obtain this
information before initiating the message retrieval protocol with the
distributors. This metadata must be published widely to prevent either the
collator or any of the distributors from attacking clients by tricking
them into thinking that the hash root of the tree is something other than
what all of the other clients know it to be, or by making a tree with
varying leaf depths. Distributors should do basic sanity checks, such as
verifying tree integrity and that all of the leaves are at the same depth.
The distributors should also send audit messages of their own to verify
that the messages correctly appear in the system. Finally, clients should
make sure that each of the distributors they use agree about the value of
the hash root.
The hash tree root used for bucket authentication uses a distinct tree
structure from the tree organization of the data in the buckets. The
authentication tree is a simple binary hash tree which can be computed
implicitly given the entire list of buckets. Binary hash trees enable the
path from any given bucket to the root to be expressed as compactly as
possible.
Distributors append to each bucket the path from that bucket to the hash
tree root. With this information, the client can verify the integrity of
information downloaded from distributors and respond to garbled data
without leaking information about which bucket it was requesting.
Delivery of excess messages for a given nym account may be conducted by
\emph{trickling} the pending messages to the distributors over the next
several tree distributions. If a client will be retrieving large amounts
of data on a regular basis, this method will not work. Instead, the client
should at account creation time request a sufficient number of buckets to
receive all data destined to it. Pending data queued on the collator
should be expired after a reasonable amount of time.
All data in the tree structure is deleted from the collator after being
passed to the distributors. This ensures that the collator has as little
information useful to an attacker as possible, and that collator resource
requirements are kept low.
Traffic from the client to the distributors should be regulated in a
manner which prevents a local observer from determining any usage pattern
information about the nym owner. This can be achieved by allowing the
client to query the distributors only at regular intervals.
\section{Scalability and Optimizations}
In this protocol, the size of requests is proportional to the total number
of messages and the size of responses is the bucket size. If one or the
other of these values is large enough to cause scaling problems, then the
collator can trade off bucket size for bit field size by doubling the
bucket size, which halves the bit field size. With this approach, if the
number of buckets becomes very large, then the message size will rise
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,
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
separate.}
The private information retrieval algorithm suggested in this paper does
not have optimal asymptotic performance. In particular, it uses more
bandwidth than necessary. We present this particular algorithm because it
is easy to explain, implement, and analyze, and offers sufficient
scalability to be useful. A reasonable engineering plan is to implement
the algorithm that we describe, then once the implementation reaches a
level of scaling high enough to warrant the much greater difficulty of a
more sophisticated algorithm, build a follow-on protocol which uses fewer
resources. Waiting to do that is prudent from a security standpoint, since
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
implement a more sophisticated algorithm will likely result in greater
resource savings once the implementation occurs.
Distributors have to perform a linear scan of their entire database in
order to fulfill a request in this protocol. However, they can compute the
results of many requests in parallel with a single linear pass through the
database. Thus, distributors can fulfill a huge number of requests, but
the latency to answer those requests is limited by the total size of all
buckets put together, with the limiting factor on that being the
distributor's hard drive throughput.
In order to minimize distributor response latency, the distributor can do
continuous linear scans of the whole database and start computing the
result of a request which comes in regardless of where it happens to be in
the scan, finishing when the next scan returns to that point again, thus
making the latency exactly the time of one full scan.
\section{A Note on Usability}
The most popular pseudonym system ever deployed was anon.penet.fi. This
system provided users with an easy, reliable way to receive mail while
hiding their true identity and email address. Subsequent attempts at
providing more secure pseudonymous mail systems have had several orders of
magnitude fewer users than 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. For instance, 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 retrive 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}
We have presented a system for anonymous
message retrieval which provides stronger anonymity assurance and greater
robustness than any other high-latency pseudonymous message retrieval
system theorized or deployed. This system, when properly utilized, resists
traffic analysis better than existing systems, and offers convenient
scalability options.
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 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
build and deploy a system based on the principles of The Pynchon Gate, it
is imperative that its effectiveness not be undermined by a poor user
interface. The most secure system is worth nothing if it is not
used.
\section{Acknowledgements}
We would like to thank Russell O'Connor, for review of several candidate
PIR systems; Adam Back, for his optimization on the message request
protocol; Lucky Green, for valuable comments; Ben Laurie, for review of an
early sketch of the Pynchon Gate Protocol; Peter Palfrader, Roger
Dingledine, and Sonia Ara\~na, for proof-reading and comments on the
paper. Finally, thanks to the many members of the Cypherpunks mailing list
who have contributed much to the field of anonymity research, in
particular Jim McCoy, whose anonymous mailbox system's architecture bears
similarity to The Pynchon Gate components.
\bibliographystyle{plain}
\bibliography{pynchon}
\end{document}
--- NEW FILE: pynchon.bib ---
@article{chaum-mix,
title = {Untraceable electronic mail, return addresses, and digital pseudonyms},
author = {David Chaum},
journal = {Communications of the ACM},
volume = {4},
number = {2},
year = {1981},
month = {February},
www_txt_url = {http://www.eskimo.com/~weidai/mix-net.txt},
www_pdf_url = {http://www.ovmj.org/GNUnet/papers/p84-chaum.pdf},
www_html_url = {http://world.std.com/~franl/crypto/chaum-acm-1981.html},
www_section = {Anonymous communication},
}
@phdthesis{ian-thesis,
title = {A Pseudonymous Communications Infrastructure for the Internet},
author = {Ian Goldberg},
school = {UC Berkeley},
year = {2000},
month = {December},
www_pdf_url = {http://www.isaac.cs.berkeley.edu/~iang/thesis-final.pdf},
www_section = {Anonymous communication},
}
@inproceedings{universal,
title = {Universal Re-Encryption for Mixnets},
author = {Philippe Golle and Markus Jakobsson and Ari Juels and Paul Syverson},
booktitle = {Proceedings of the 2004 RSA Conference, Cryptographer's track},
year = {2004},
month = {February},
address = {San Francisco, USA},
www_section = {Anonymous communication},
www_pdf_url = {http://www.syverson.org/univrenc-ctrsa.pdf},
}
@inproceedings{fiveyearslater,
title = {{Privacy-enhancing technologies for the Internet, II: Five years later}},
author = {Ian Goldberg},
booktitle = {Proceedings of Privacy Enhancing Technologies workshop (PET 2002)},
year = {2002},
month = {April},
editor = {Roger Dingledine and Paul Syverson},
publisher = {Springer-Verlag, LNCS 2482},
www_section = {Misc},
}
@inproceedings{beimel-barrier,
title = {Breaking the $O(n^1/(2k-1))$ Barrier for Information-Theoretic Private Information Retrieval},
author = {Amos Beimel and Yuval Ishai and Eyal Kushilevitz and Jean-Fran\c{c}ois Raymond},
booktitle = {Proceedings of the 43rd IEEE Symposium on Foundations of Computer Science (FOCS)},
year = {2002},
www_pdf_url = {http://www.cs.bgu.ac.il/~beimel/Papers/BIKR.pdf},
}
@inproceedings{nym-alias-net,
title = {{The Design, Implementation and Operation of an Email Pseudonym Server}},
author = {David Mazi\`eres and M. Frans Kaashoek},
booktitle = {Proceedings of the 5th ACM Conference on Computer and Communications
Security (CCS'98)},
year = {1998},
month = {November},
publisher = {ACM Press},
www_pdf_url = {ftp://cag.lcs.mit.edu/pub/dm/papers/mazieres:pnym.pdf},
www_section = {Pseudonymity},
}
@inproceedings{mixminion,
title = {{Mixminion: Design of a Type III Anonymous Remailer Protocol}},
author = {George Danezis and Roger Dingledine and Nick Mathewson},
booktitle = {Proceedings of the 2003 IEEE Symposium on Security and Privacy},
year = {2003},
month = {May},
www_pdf_url = {http://mixminion.net/minion-design.pdf},
www_important = {1},
www_section = {Anonymous communication},
}
@inproceedings{disad-free-routes,
title = {The disadvantages of free {MIX} routes and how to overcome them},
author = {Oliver Berthold and Andreas Pfitzmann and Ronny Standtke},
booktitle = {Proceedings of Designing Privacy Enhancing Technologies: Workshop on Design
Issues in Anonymity and Unobservability},
year = {2000},
month = {July},
pages = {30--45},
editor = {H. Federrath},
publisher = {Springer-Verlag, LNCS 2009},
www_important = {1},
www_section = {Traffic analysis},
www_pdf_url = {http://www.tik.ee.ethz.ch/~weiler/lehre/netsec/Unterlagen/anon/disadvantages_berthold.pdf},
}
@inproceedings{goldschlag96,
author = {David M. Goldschlag and Michael G. Reed and Paul F. Syverson},
title = {Hiding Routing Information},
booktitle = {Information Hiding},
pages = {137-150},
year = {1996},
www_pdf_url = {http://www.onion-router.net/Publications/IH-1996.pdf},
}
@inproceedings{statistical-disclosure,
title = {Statistical Disclosure Attacks: Traffic Confirmation in Open Environments},
author = {George Danezis},
booktitle = {Proceedings of Security and Privacy in the Age of Uncertainty, ({SEC2003})},
organization = {{IFIP TC11}},
year = {2003},
month = {May},
address = {Athens},
pages = {421--426},
editor = {Gritzalis and Vimercati and Samarati and Katsikas},
publisher = {Kluwer},
www_section = {Traffic analysis},
www_pdf_url = {http://www.cl.cam.ac.uk/~gd216/StatDisclosure.pdf},
}
@inproceedings{bittorrent,
author = {Bram Cohen},
title = {Incentives Build Robustness in BitTorrent},
booktitle = {Workshop on Economics of Peer-to-Peer Systems},
year = {2003},
month = {May},
address = {Berkeley, CA},
www_pdf_url = {http://www.sims.berkeley.edu/research/conferences/p2pecon/papers/s4-cohen.pdf},
}
@inproceedings{pir,
title = {Private Information Retrieval},
author = {Benny Chor and Oded Goldreich and Eyal Kushilevitz and Madhu Sudan},
booktitle = {{IEEE} Symposium on Foundations of Computer Science},
pages = {41-50},
year = {1995},
www_ps_url = {http://theory.lcs.mit.edu/~madhu/papers/pir-journ.ps},
}
@article{beimel01informationtheoretic,
author = {Amos Beimel and Yuval Ishai},
title = {Information-Theoretic Private Information Retrieval: {A} Unified Construction},
journal = {Lecture Notes in Computer Science},
volume = {2076},
pages = {89--98},
year = {2001},
www_pdf_url = {http://www.cs.bgu.ac.il/~beimel/Papers/BI.pdf},
}
@techreport{freedom2-arch,
title = {Freedom Systems 2.0 Architecture},
author = {Philippe Boucher and Adam Shostack and Ian Goldberg},
institution = {Zero Knowledge Systems, {Inc.}},
year = {2000},
month = {December},
type = {White Paper},
www_pdf_url = {http://osiris.978.org/~brianr/crypto-research/anon/www.freedom.net/products/whitepapers/Freedom_System_2_Architecture.pdf},
www_section = {Anonymous communication},
day = {18},
}
@techreport{freedom2-mail,
title = {Freedom 2.0 Mail System},
author = {Roger McFarlane and Adam Back and Graydon Hoare and Serge Chevarie-Pelletier and Bill Heelan and Christian Paquin and Deniz Sarikaya},
institution = {Zero Knowledge Systems, {Inc.}},
year = {2000},
month = {December},
type = {White Paper},
www_pdf_url = {http://www.cypherspace.org/~adam/pubs/freedom2-mail.pdf},
www_section = {Anonymous communication},
day = {19},
}
@misc{harmful,
author = {Anonymous},
title = {alt.anonymous.messages Considered Harmful},
year = {1995},
month = {November},
howpublished = {Mailing list post},
url = {http://cypherpunks.venona.com/date/1995/11/msg00089.html},
}
@misc{aam,
author = {Rick Busdiecker},
title = {Message pool: alt.anonymous.messages},
year = {1994},
month = {August},
howpublished = {Mailing list post},
url = {http://cypherpunks.venona.com/date/1994/08/msg00185.html},
}
@Misc{remailer-attacks,
author = {Lance Cottrell},
title = {Mixmaster and Remailer Attacks},
note = {\url{http://www.obscura.com/~loki/remailer/remailer-essay.html}},
}
@misc{replay,
author = {Lance Cottrell},
title = {Re: Strengthening Remailer Protocols},
year = {1996},
month = {September},
howpublished = {Mailing list post},
url = {http://cypherpunks.venona.com/date/1996/09/msg00730.html},
}
@misc{surb,
author = {Mike Ingle},
title = {Interoperability, One-use Remailer Tickets},
year = {1994},
month = {December},
howpublished = {Mailing list post},
url = {http://cypherpunks.venona.com/date/1994/12/msg00245.html},
}
@misc{pop-mix,
author = {Andrew Loewenstern},
title = {Re: Strengthening Remailer Protocols},
year = {1996},
month = {September},
howpublished = {Mailing list post},
url = {http://cypherpunks.venona.com/date/1996/09/msg00898.html},
}
@misc{tcmay,
author = {Tim May},
title = {Re: Strengthening Remailer Protocols},
year = {1996},
month = {September},
howpublished = {Mailing list post},
url = {http://cypherpunks.venona.com/date/1996/09/msg00167.html},
}
@misc{pipenet,
title = {PipeNet 1.1},
author = {Wei Dai},
year = {1996},
month = {August},
howpublished = {Usenet post},
www_section = {Anonymous communication},
www_txt_url = {http://www.eskimo.com/~weidai/pipenet.txt},
}
@misc{prng-back,
title = {Personal Communication},
author = {Adam Back},
year = {2003},
month = {April},
}
@misc{sassaman-lisa,
title = {The Promise of Privacy},
author = {Len Sassaman},
year = {2002},
month = {November},
howpublished = {Invited talk, LISA XVI},
organization = {USENIX}
}
@misc{danezis-traffic-analysis,
title = {Personal Communication, further citation forthcoming},
author = {George Danezis},
year = {2003},
month = {April},
}
@misc{mixmaster-spec,
title = {Mixmaster {P}rotocol --- {V}ersion 2},
author = {Ulf M\"oller and Lance Cottrell and Peter Palfrader and Len Sassaman},
year = {2003},
month = {July},
www_section = {Anonymous communication},
www_txt_url = {http://www.abditum.com/mixmaster-spec.txt},
}
@misc{tor-design,
title = {{Tor: The Second-Generation Onion Router}},
author = "Roger Dingledine and Nick Mathewson and Paul Syverson",
month = {January},
year = {2004},
howpublished = {Manuscript},
}
@misc{echolot,
author = {Peter Palfrader},
title = {Echolot: a pinger for anonymous remailers},
note = {\url{http://www.palfrader.org/echolot/}},
}
--- NEW FILE: llncs.cls ---
% LLNCS DOCUMENT CLASS -- version 2.8
% for LaTeX2e
%
\NeedsTeXFormat{LaTeX2e}[1995/12/01]
\ProvidesClass{llncs}[2000/05/16 v2.8
^^JLaTeX document class for Lecture Notes in Computer Science]
% Options
\let\if@envcntreset\iffalse
\DeclareOption{envcountreset}{\let\if@envcntreset\iftrue}
\DeclareOption{citeauthoryear}{\let\citeauthoryear=Y}
\DeclareOption{oribibl}{\let\oribibl=Y}
\let\if@custvec\iftrue
\DeclareOption{orivec}{\let\if@custvec\iffalse}
\let\if@envcntsame\iffalse
\DeclareOption{envcountsame}{\let\if@envcntsame\iftrue}
\let\if@envcntsect\iffalse
\DeclareOption{envcountsect}{\let\if@envcntsect\iftrue}
\let\if@runhead\iffalse
\DeclareOption{runningheads}{\let\if@runhead\iftrue}
[...977 lines suppressed...]
\def\subsectionmark##1{}}
\def\ps@titlepage{\let\@mkboth\@gobbletwo
\let\@oddfoot\@empty\let\@evenfoot\@empty
\def\@evenhead{\normalfont\small\rlap{\thepage}\hspace{\headlineindent}%
\hfil}
\def\@oddhead{\normalfont\small\hfil\hspace{\headlineindent}%
\llap{\thepage}}
\def\chaptermark##1{}%
\def\sectionmark##1{}%
\def\subsectionmark##1{}}
\if@runhead\ps@headings\else
\ps@empty\fi
\setlength\arraycolsep{1.4\p@}
\setlength\tabcolsep{1.4\p@}
\endinput
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/