mirrors/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-20 10:12:15 +01:00
Code Issues Projects Releases Wiki Activity

Router twins described in intro. Some more stuff in assumptions section.

Browse Source 
svn:r661
This commit is contained in:
Paul Syverson 2003-10-22 22:40:30 +00:00
parent 4e3345ff08
commit 8ee82830b4
1 changed files with 36 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
doc/tor-design.tex
View File

@ -168,7 +168,20 @@ the fly so it connects to a different webserver, or by tagging encrypted
traffic and looking for traffic at the network edges that has been
tagged \cite{minion-design}.
\item \textbf{Robustness to node failure:} router twins
\item \textbf{Robustness to node failure:} Node failure for a
low-latency system like Tor is not as serious a problem as it is for
a traditional mix network. Nonetheless, simple mechanisms that allow
connections to be established despite slightly dated information
from a directory server or very recent node failure are useful. Tor
permits onion routers to have router twins. These share the same
private decryption key that is used when establishing a connection
through the onion router. Note that because of how connections are
now established with perfect forward secrecy, this does not
automatically mean that an onion router can read the traffic on a
connection established through its twin even while that connection
is active. Also, which nodes are twins can change dynamically
depending on current circumstances, and twins may or may not be
under the same administrative authority.
\item \textbf{Exit policies:}
Tor provides a consistent mechanism for each node to specify and
@ -545,23 +558,32 @@ tagging attacks
\SubSection{Assumptions}
All dirservers are honest and trusted.
For purposes of this paper, we assume all directory servers are honest
and trusted. Perhaps more accurately, we assume that all users and
nodes can perform their own periodic checks on information they have
from directory servers and that all will always have access to at
least one directory server that they trust and from which they obtain
all directory information. Future work may include robustness
techniques to cope with a minority dishonest servers.
Somewhere between ten percent and twenty percent of nodes
are compromised. In some circumstances, e.g., if the Tor network
is running on a hardened network where all operators have had careful
Somewhere between ten percent and twenty percent of nodes are assumed
to be compromised. In some circumstances, e.g., if the Tor network is
running on a hardened network where all operators have had careful
background checks, the percent of compromised nodes might be much
lower. Also, it may be worthwhile to consider cases where many
of the `bad' nodes are not fully compromised but simply (passive)
observing adversaries. We assume that all adversary components,
regardless of their capabilities are collaborating and are connected
in an offline clique.
lower. It may be worthwhile to consider cases where many of the `bad'
nodes are not fully compromised but simply (passive) observing
adversaries or that some nodes have only had compromise of the keys
that decrypt connection initiation requests. But, we assume for
simplicity that `bad' nodes are compromised in the sense spelled out
above. We assume that all adversary components, regardless of their
capabilities are collaborating and are connected in an offline clique.
We do not assume any hostile users, except in the context of
rendezvous points. Nonetheless, we assume that users vary widely in
both the duration and number of times they are connected to the Tor
network. They can also be assumed to vary widely in the volume and
shape of the traffic they send and receive.
- Threat model
- Mostly reliable nodes: not trusted.
- Small group of trusted dirserv ops
- Many users of diff bandwidth come and go.
[XXX what else?]