[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] Cleaned up some typos, typesetting issues, and added...
Update of /home2/freehaven/cvsroot/doc/pynchon-gate
In directory moria.mit.edu:/tmp/cvs-serv14062
Modified Files:
pynchon.bib pynchon.tex
Log Message:
Cleaned up some typos, typesetting issues, and added some missing
citations. Added a footnote about ElGamal.
Index: pynchon.bib
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.bib,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -d -r1.4 -r1.5
--- pynchon.bib 26 Jan 2004 11:39:06 -0000 1.4
+++ pynchon.bib 26 Jan 2004 22:56:42 -0000 1.5
@@ -12,6 +12,28 @@
www_section = {Anonymous communication},
}
+@article{wagner,
+ author = {Robyn Wagner},
+ title = {{Don't Shoot the Messenger: Limiting the Liability of Anonymous Remailer Operators}},
+ journal = {New Mexico Law Review},
+ volume = {32},
+ number = {Winter},
+ pages = {99--142},
+ year = {2002},
+}
+
+@article{elgamal,
+ title = {{A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms}},
+ author = {Taher ElGamal},
+ journal = {{IEEE} Transactions on Information Theory},
+ volume = {IT-31},
+ number = {4},
+ pages = {469--472},
+ year = {1985},
+}
+
+
+
@phdthesis{ian-thesis,
title = {A Pseudonymous Communications Infrastructure for the Internet},
author = {Ian Goldberg},
@@ -28,11 +50,19 @@
booktitle = {Proceedings of the 2004 RSA Conference, Cryptographer's track},
year = {2004},
month = {February},
- address = {San Francisco, USA},
+ address = {San Francisco, CA, USA},
www_section = {Anonymous communication},
www_pdf_url = {http://www.syverson.org/univrenc-ctrsa.pdf},
}
+@inproceedings{bleichenbacher,
+ title = {Generating {E}l{G}amal signatures without knowing the secret key},
+ author = {Daniel Bleichenbacher},
+ booktitle = {Eurocrypt 96},
+ year = {1996},
+ ftp_ps_url = {ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps},
+}
+
@inproceedings{fiveyearslater,
title = {{Privacy-enhancing technologies for the Internet, II: Five years later}},
author = {Ian Goldberg},
@@ -136,7 +166,7 @@
booktitle = {Workshop on Economics of Peer-to-Peer Systems},
year = {2003},
month = {May},
- address = {Berkeley, CA},
+ address = {Berkeley, CA, USA},
www_pdf_url = {http://www.sims.berkeley.edu/research/conferences/p2pecon/papers/s4-cohen.pdf},
}
@@ -183,6 +213,15 @@
day = {19},
}
+@misc{hal-remailer,
+ author = {Hal Finney},
+ title = {New remailer...},
+ year = {1992},
+ month = {Octgober},
+ howpublished = {Mailing list post},
+ url = {http://cypherpunks.venona.com/date/1992/10/msg00082.html},
+}
+
@misc{harmful,
author = {Anonymous},
title = {alt.anonymous.messages Considered Harmful},
@@ -254,7 +293,7 @@
}
@misc{alpha-faq,
- title = {FAQ for the ALPHA.C2.ORG Remailer},
+ title = {{FAQ} for the {ALPHA.C2.ORG} {R}emailer},
author = {Andre Bacard},
year = {1995},
month = {October},
@@ -269,6 +308,15 @@
month = {April},
}
+@misc{imap-over-minion,
+ title = {Hallway discussion at the Computers, Freedom, and
+ Privacy Conference},
+ author = {Len Sassaman and George Danezis},
+ year = {2002},
+ month = {April},
+ address = {San Francisco, CA, USA},
+}
+
@misc{sassaman-lisa,
title = {The Promise of Privacy},
author = {Len Sassaman},
@@ -285,6 +333,31 @@
month = {April},
}
+@misc{nguyen,
+ title = {Unpublished research},
+ author = {Phong Q. Nguyen},
+ year = {2003},
+ month = {November},
+}
+
+@misc{pgp5-elgamal,
+ title = {{Re: ElGamal signature encoding}},
+ author = {Hal Finney},
+ year = {1998},
+ month = {April},
+ howpublished = {Mailing list post},
+ url = {http://www.privacy.nb.ca/cryptography/archives/coderpunks/new/1998-04/0050.html},
+}
+
+@misc{gpg-compromised,
+ title = {{GnuPG's ElGamal signing keys compromised}},
+ author = {Werner Koch},
+ year = {2003},
+ month = {November},
+ howpublished = {Mailing list post},
+ url = {http://lists.gnupg.org/pipermail/gnupg-announce/2003q4/000276.html},
+}
+
@misc{mixmaster-spec,
title = {Mixmaster {P}rotocol --- {V}ersion 2},
author = {Ulf M\"oller and Lance Cottrell and Peter Palfrader and Len Sassaman},
@@ -294,12 +367,22 @@
www_txt_url = {http://www.abditum.com/mixmaster-spec.txt},
}
+@misc{rfc-2779,
+ title = {{Instant Messaging / Presence Protocol Requirements}},
+ author = {M. Day and S. Aggarwal and G. Mohr and J. Vincent},
+ year = {2000},
+ month = {February},
+ organization = {Internet Engineering Task Force},
+ howpublished = {Request for Comments: 2779},
+ www_txt_url = {http://www.ietf.org/rfc/rfc2779.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},
+ title = {{Tor: The Second-Generation Onion Router}},
+ author = "Roger Dingledine and Nick Mathewson and Paul Syverson",
+ month = {January},
+ year = {2004},
+ howpublished = {Manuscript},
}
@misc{echolot,
@@ -307,3 +390,10 @@
title = {Echolot: a pinger for anonymous remailers},
note = {\url{http://www.palfrader.org/echolot/}},
}
+
+@misc{helsingius,
+ author = {Johan Helsingius},
+ title = {press release announcing closure of anon.penet.fi},
+ howpublished = {http://www.penet.fi/press-english.html},
+}
+
Index: pynchon.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- pynchon.tex 26 Jan 2004 11:33:59 -0000 1.5
+++ pynchon.tex 26 Jan 2004 22:56:42 -0000 1.6
@@ -18,7 +18,7 @@
\institute{Anonymizer, Inc., \\
5694 Mission Center Road, Suite 426, \\
San Diego, CA 92108-4380 USA. \\
-\email{rabbi@abditum.com}
+\email{rabbi@anonymizer.com}
\and
BitTorrent, \\
2018 Shattuck Avenue, Suite 124, \\
@@ -76,12 +76,12 @@
\subsection{Related Work}
-\subsubsection{Reply blocks and return addresses}
+\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
+component nodes of the mix being operational in order for mail to be
+delivered. 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
@@ -89,28 +89,30 @@
the remailer network.}
In addition to reliability issues, simple reply-block systems suffer from
-a pseudonym management perspective. Cypherpunk nym servers such as
-alpha.c2.net~\cite{alpha-faq} and nym.alias.net~\cite{nym-alias-net}
-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}.
+a pseudonym management perspective. Cypherpunk nym servers based on the
+first generation implementation of Chaum's mix-nets (Type I
+remailers~\cite{hal-remailer}), such as {\tt
+alpha.c2.net}~\cite{alpha-faq} and {\tt
+nym.alias.net}~\cite{nym-alias-net}, implemented the concept of a central
+reply-block repository which allowed pseudonym-holders to receive messages
+delivered to a traditional email address. Unfortunately, reply-block
+systems based 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 (Mixmaster) and Type III
+(Mixminion~\cite{mixminion}) systems do not permit multiple-use reply
+blocks, and contain replay-attack protection mechanisms~\cite{replay}.
-\subsubsection{Single-use reply blocks}
+\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
+reply blocks, the Type III system 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.
@@ -124,21 +126,21 @@
correlation~\cite{statistical-disclosure}.
-\subsubsection {Network-level client anonymity}
+\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
+The ZKS 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}
+\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
@@ -152,7 +154,7 @@
anonymity systems for anonymous mail receipt; however, they do not address
the previously mentioned concerns with these anonymity systems.
-\subsubsection{Re-encryption mixes}
+\subsubsection{Re-encryption mixes.}
Re-encryption mixes~\cite {universal} aim to improve the reliability of
anonymous message systems. Recent work has shown that re-encryption mixes
@@ -171,7 +173,14 @@
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.
+first achieved wide deployment.\footnote{Re-encryption mixes rely on the
+ElGamal cryptosystem~\cite{elgamal}, aspects of which have been discovered
+to contain flaws~\cite{bleichenbacher}~\cite{nguyen} which have
+significantly affected deployed cryptographic
+applications~\cite{pgp5-elgamal}~\cite{gpg-compromised}. While these
+particular flaws are related to ElGamal signature schemes rather than the
+encryption techniques used by re-encryption mixes, general concerns about
+implementation security of the ElGamal cryptosystem remain.}
\subsubsection{Broadcast messages and dead-drops.}
@@ -182,17 +191,17 @@
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.
+newsgroup and are behaving in an identical manner (for instance, by
+downloading the entire set of newsgroup messages daily), the possible
+statistical attacks on direct mail delivery of reply messages to
+individual email addresses are avoided. This solution 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
+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
@@ -204,24 +213,29 @@
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.
+pseudonym accounts via email\footnote {The servers could also receive
+messages through any suitable medium for message transfer, such as
+``instant message'' systems~\cite {rfc-2779}. Note that there must exist a
+suitable forward anonymity protocol to allow the nym holder to communicate
+with the nym server, so at a minimum the nym server must be able to
+receive email in addition to any optional support for other protocols.
+Future developments in forward anonymity protocols may alleviate this
+reliance on email.} 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,
+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.
+with limited resources. The information theory-based PIR primitive allows
+us 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}
@@ -259,9 +273,9 @@
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.
+address and key from the nym server though an active attack on those
+components. The attacker would then be able to read all messages that nym
+has ever received.
\subsection{The Collator}
@@ -320,7 +334,9 @@
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.
+discarded\footnote{This ``INBOX management'' protocol is similar to one
+which has been proposed as the basis for the Mixminion nym
+servers~\cite{imap-over-minion}}.
\section{Security Concerns}
@@ -387,11 +403,11 @@
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.}
+point in a legal attack~\cite{nym-alias-net}~\cite{wagner} 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
@@ -407,7 +423,10 @@
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.
+resource savings once the implementation occurs.\footnote {Modifications
+to the protocol which break compatibility with existing clients should be
+made cautiously, however, to avoid unnecessary fragmentation of the
+existing anonymity set.}
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
@@ -425,19 +444,19 @@
\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.
+The most popular pseudonym system ever deployed was {\tt
+anon.penet.fi}~\cite{helsingius}. 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 unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/