mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-28 06:13:31 +01:00
Remove references to byzantine fault tolerance, clean up directory discussions
svn:r708
This commit is contained in:
parent
2b39ec4f2e
commit
e8b701dae9
@ -105,14 +105,6 @@
|
|||||||
pages = {49--54},
|
pages = {49--54},
|
||||||
}
|
}
|
||||||
|
|
||||||
@inproceedings{castro-liskov,
|
|
||||||
author = {Miguel Castro and Barbara Liskov},
|
|
||||||
title = {Proactive Recovery in a Byzantine-Fault-Tolerant System},
|
|
||||||
booktitle = {Fourth Symposium on Operating Systems Design and Implementation},
|
|
||||||
month = {October},
|
|
||||||
year = {2000},
|
|
||||||
}
|
|
||||||
|
|
||||||
@inproceedings{econymics,
|
@inproceedings{econymics,
|
||||||
title = {On the Economics of Anonymity},
|
title = {On the Economics of Anonymity},
|
||||||
author = {Alessandro Acquisti and Roger Dingledine and Paul Syverson},
|
author = {Alessandro Acquisti and Roger Dingledine and Paul Syverson},
|
||||||
|
@ -1345,46 +1345,43 @@ behavior, whereas Tor only needs a threshold consensus of the current
|
|||||||
state of the network.
|
state of the network.
|
||||||
% Cite dir-spec or dir-agreement?
|
% Cite dir-spec or dir-agreement?
|
||||||
|
|
||||||
The threshold consensus can be reached with standard Byzantine agreement
|
Tor directory servers build a consensus directory through a simple
|
||||||
techniques \cite{castro-liskov}.
|
four-round broadcast protocol. In round one, each server dates and
|
||||||
% Should I just stop the section here? Is the rest crap? -RD
|
signs its current opinion, and broadcasts it to the other directory
|
||||||
% IMO this graf makes me uncomfortable. It picks a fight with the
|
servers; then in round two, each server rebroadcasts all the signed
|
||||||
% Byzantine people for no good reason. -NM
|
opinions it has received. At this point all directory servers check
|
||||||
But this library, while more efficient than previous Byzantine agreement
|
to see whether any server has signed multiple opinions in the same
|
||||||
systems, is still complex and heavyweight for our purposes: we only need
|
period. If so, the server is either broken or cheating, so protocol
|
||||||
to compute a single algorithm, and we do not require strict in-order
|
stops and notifies the administrators, who either remove the cheater
|
||||||
computation steps. Indeed, the complexity of Byzantine agreement protocols
|
or wait for the broken server to be fixed. If there are no
|
||||||
threatens our security, because users cannot easily understand it and
|
discrepancies, each directory server then locally computes algorithm
|
||||||
thus have less trust in the directory servers. The Tor directory servers
|
on the set of opinions, resulting in a uniform shared directory. In
|
||||||
build a consensus directory
|
round three servers sign this directory and broadcast it; and finally
|
||||||
through a simple four-round broadcast protocol. First, each server signs
|
in round four the servers rebroadcast the directory and all the
|
||||||
and broadcasts its current opinion to the other directory servers; each
|
signatures. If any directory server drops out of the network, its
|
||||||
server then rebroadcasts all the signed opinions it has received. At this
|
signature is not included on the file directory.
|
||||||
point all directory servers check to see if anybody's cheating. If so,
|
|
||||||
directory service stops, the humans are notified, and that directory
|
|
||||||
server is permanently removed from the network. Assuming no cheating,
|
|
||||||
each directory server then computes a local algorithm on the set of
|
|
||||||
opinions, resulting in a uniform shared directory. Then the servers sign
|
|
||||||
this directory and broadcast it; and finally all servers rebroadcast
|
|
||||||
the directory and all the signatures.
|
|
||||||
|
|
||||||
The rebroadcast steps ensure that a directory server is heard by either
|
The rebroadcast steps ensure that a directory server is heard by
|
||||||
all of the other servers or none of them (some of the links between
|
either all of the other servers or none of them, assuming that any two
|
||||||
directory servers may be down). Broadcasts are feasible because there
|
directories can talk directly, or via a third directory (some of the
|
||||||
are so few directory servers (currently 3, but we expect to use as many
|
links between directory servers may be down). Broadcasts are feasible
|
||||||
as 9 as the network scales). The actual local algorithm for computing
|
because there are relatively few directory servers (currently 3, but we expect
|
||||||
the shared directory is straightforward, and is described in the Tor
|
to use as many as 9 as the network scales). The actual local algorithm
|
||||||
specification \cite{tor-spec}.
|
for computing the shared directory is a straightforward threshold
|
||||||
% we should, uh, add this to the spec. oh, and write it. -RD
|
voting process: we include an OR if a majority of directory servers
|
||||||
|
believe it to be good.
|
||||||
|
|
||||||
Using directory servers rather than flooding approaches provides
|
When a client Alice retrieves a consensus directory, she uses it if it
|
||||||
simplicity and flexibility. For example, they don't complicate
|
is signed by a majority of the directory servers she knows.
|
||||||
the analysis when we start experimenting with non-clique network
|
|
||||||
topologies. And because the directories are signed, they can be cached at
|
Using directory servers rather than flooding provides simplicity and
|
||||||
all the other onion routers (or even elsewhere). Thus directory servers
|
flexibility. For example, they don't complicate the analysis when we
|
||||||
are not a performance bottleneck when we have many users, and also they
|
start experimenting with non-clique network topologies. And because
|
||||||
won't aid traffic analysis by forcing clients to periodically announce
|
the directories are signed, they can be cached by other onion routers,
|
||||||
their existence to any central point.
|
or indeed by any server. Thus directory servers are not a performance
|
||||||
|
bottleneck when we have many users, and do not aid traffic analysis by
|
||||||
|
forcing clients to periodically announce their existence to any
|
||||||
|
central point.
|
||||||
% Mention Hydra as an example of non-clique topologies. -NM, from RD
|
% Mention Hydra as an example of non-clique topologies. -NM, from RD
|
||||||
|
|
||||||
% also find some place to integrate that dirservers have to actually
|
% also find some place to integrate that dirservers have to actually
|
||||||
|
Loading…
Reference in New Issue
Block a user