clean up bib; remove incorrect directory consensus discussion

svn:r1885
This commit is contained in:
Roger Dingledine 2004-05-18 06:14:29 +00:00
parent fd09a4080b
commit 92c4b3f139
2 changed files with 11 additions and 34 deletions

View File

@ -91,7 +91,7 @@
@inproceedings{eax,
author = "M. Bellare and P. Rogaway and D. Wagner",
title = "The EAX Mode of Operation: A Two-Pass Authenticated-Encryption Scheme Optimized for Simplicity and Efficiency",
title = {The {EAX} Mode of Operation: A Two-Pass Authenticated-Encryption Scheme Optimized for Simplicity and Efficiency},
booktitle = {Fast Software Encryption 2004},
month = {February},
year = {2004},
@ -258,7 +258,7 @@
@InProceedings{sybil,
author = "John Douceur",
title = {{The Sybil Attack}},
booktitle = "Proceedings of the 1st International Peer To Peer Systems Workshop (IPTPS 2002)",
booktitle = "Proceedings of the 1st International Peer To Peer Systems Workshop (IPTPS)",
month = Mar,
year = 2002,
}
@ -915,7 +915,7 @@
title = {Passive Attack Analysis for Connection-Based Anonymity Systems},
author = {Andrei Serjantov and Peter Sewell},
booktitle = {Computer Security -- ESORICS 2003},
publisher = {Springer-Verlag, LNCS (forthcoming)},
publisher = {Springer-Verlag, LNCS 2808},
year = {2003},
month = {October},
}
@ -1014,7 +1014,7 @@
@InProceedings{p5,
author = {Rob Sherwood and Bobby Bhattacharjee and Aravind Srinivasan},
title = {$P^5$: A Protocol for Scalable Anonymous Communication},
booktitle = {2002 IEEE Symposium on Security and Privacy},
booktitle = {IEEE Symposium on Security and Privacy},
pages = {58--70},
year = 2002,
publisher = {IEEE CS}

View File

@ -1379,39 +1379,16 @@ we make the
simplifying assumption that all participants agree on the set of
directory servers. Second, while Mixminion needs to predict node
behavior, Tor only needs a threshold consensus of the current
state of the network.
% XXXX Do we really want this next part? It isn't really sound, and
% XXXX we haven't implemented it. -NM
Tor directory servers build a consensus directory through a simple
four-round broadcast protocol. In round one, each server dates and
signs its current opinion, and broadcasts it to the other directory
servers; then in round two, each server rebroadcasts all the signed
opinions it has received. At this point all directory servers check
to see whether any server has signed multiple opinions in the same
period. Such a server is either broken or cheating, so the protocol
stops and notifies the administrators, who either remove the cheater
or wait for the broken server to be fixed. If there are no
discrepancies, each directory server then locally computes an algorithm
(described below)
on the set of opinions, resulting in a uniform shared directory. In
round three servers sign this directory and broadcast it; and finally
in round four the servers rebroadcast the directory and all the
signatures. If any directory server drops out of the network, its
signature is not included on the final directory.
The rebroadcast steps ensure that a directory server is heard by
either all of the other servers or none of them, even when some links
are down (assuming that any two directory servers can talk directly or
via a third). Broadcasts are feasible because there are relatively few
directory servers (currently 3, but we expect as many as 9 as the network
scales). Computing the shared directory locally is a straightforward
threshold voting process: we include an OR if a majority of directory
servers believe it to be good.
state of the network. Third, we assume that we can fall back to the
human administrators to discover and resolve problems when a concensus
directory cannot be reached. Since there are relatively few directory
servers (currently 3, but we expect as many as 9 as the network scales),
we can afford operations like broadcast to simplify the consensus-building
protocol.
To avoid attacks where a router connects to all the directory servers
but refuses to relay traffic from other routers, the directory servers
must build circuits and use them to anonymously test router
must also build circuits and use them to anonymously test router
reliability~\cite{mix-acc}. Unfortunately, this defense is not yet
designed or
implemented.