[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[freehaven-cvs] Fixed some wording issues, typos.
Update of /home2/freehaven/cvsroot/doc/pynchon-gate
In directory moria.mit.edu:/tmp/cvs-serv21777
Modified Files:
pynchon.bib pynchon.tex
Log Message:
Fixed some wording issues, typos.
Index: pynchon.bib
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.bib,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -d -r1.5 -r1.6
--- pynchon.bib 26 Jan 2004 22:56:42 -0000 1.5
+++ pynchon.bib 27 Jan 2004 02:02:38 -0000 1.6
@@ -60,6 +60,8 @@
author = {Daniel Bleichenbacher},
booktitle = {Eurocrypt 96},
year = {1996},
+ month = {May},
+ address = {Zaragoza, Spain},
ftp_ps_url = {ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps},
}
@@ -145,6 +147,19 @@
www_section = {Anonymous communication},
}
+@inproceedings{trickle02,
+ title = {From a Trickle to a Flood: Active Attacks on Several Mix Types},
+ author = {Andrei Serjantov and Roger Dingledine and Paul Syverson},
+ booktitle = {Proceedings of Information Hiding Workshop (IH 2002)},
+ year = {2002},
+ month = {October},
+ editor = {Fabien Petitcolas},
+ publisher = {Springer-Verlag, LNCS 2578},
+ www_pdf_url = {http://freehaven.net/doc/batching-taxonomy/taxonomy.pdf},
+ www_ps_url = {http://freehaven.net/doc/batching-taxonomy/taxonomy.ps},
+ www_section = {Traffic analysis},
+}
+
@inproceedings{statistical-disclosure,
title = {Statistical Disclosure Attacks: Traffic Confirmation in Open Environments},
author = {George Danezis},
@@ -162,7 +177,7 @@
@inproceedings{bittorrent,
author = {Bram Cohen},
- title = {Incentives Build Robustness in BitTorrent},
+ title = {{Incentives Build Robustness in BitTorrent}},
booktitle = {Workshop on Economics of Peer-to-Peer Systems},
year = {2003},
month = {May},
Index: pynchon.tex
===================================================================
RCS file: /home2/freehaven/cvsroot/doc/pynchon-gate/pynchon.tex,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -d -r1.7 -r1.8
--- pynchon.tex 26 Jan 2004 23:35:04 -0000 1.7
+++ pynchon.tex 27 Jan 2004 02:02:38 -0000 1.8
@@ -175,7 +175,7 @@
and in many cases flaws remained unnoticed until years after a system
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
+to contain flaws~\cite{bleichenbacher}~\cite{nguyen} that 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
@@ -279,7 +279,7 @@
\subsection{The Collator}
-Messages for nym owners are passed to the collator component\footnote{The
+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
@@ -334,9 +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\footnote{This ``INBOX management'' protocol is similar to one
+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}}.
+servers~\cite{imap-over-minion}.}
\section{Security Concerns}
@@ -374,13 +374,16 @@
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.
+Message buckets must be of a fixed size in order to protect against
+attacks similar to the active flooding attacks on mix-net systems~\cite
+{trickle02} as well as simple usage pattern analysis. 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
@@ -481,16 +484,15 @@
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.
+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 provides no value if it is not used.
\section{Acknowledgments}
***********************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe freehaven-cvs in the body. http://freehaven.net/