Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
Tor
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Container Registry
Model registry
Monitor
Incidents
Service Desk
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
The Tor Project
Core
Tor
Commits
92c4b3f1
Commit
92c4b3f1
authored
20 years ago
by
Roger Dingledine
Browse files
Options
Downloads
Patches
Plain Diff
clean up bib; remove incorrect directory consensus discussion
svn:r1885
parent
fd09a408
No related branches found
No related tags found
No related merge requests found
Changes
2
Hide whitespace changes
Inline
Side-by-side
Showing
2 changed files
doc/tor-design.bib
+4
-4
4 additions, 4 deletions
doc/tor-design.bib
doc/tor-design.tex
+7
-30
7 additions, 30 deletions
doc/tor-design.tex
with
11 additions
and
34 deletions
doc/tor-design.bib
+
4
−
4
View file @
92c4b3f1
...
...
@@ -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}
...
...
This diff is collapsed.
Click to expand it.
doc/tor-design.tex
+
7
−
30
View file @
92c4b3f1
...
...
@@ -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.
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment