mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 05:03:43 +01:00
Edits to edits. Revert change to central gutter width; cut back down to under 15 pages.
svn:r766
This commit is contained in:
parent
6c68317577
commit
b6f88fc066
@ -59,8 +59,8 @@
|
||||
% set dimensions of columns, gap between columns, and paragraph indent
|
||||
\setlength{\textheight}{8.875in}
|
||||
\setlength{\textwidth}{6.875in}
|
||||
%\setlength{\columnsep}{0.3125in}
|
||||
\setlength{\columnsep}{0.26in}
|
||||
\setlength{\columnsep}{0.3125in}
|
||||
%\setlength{\columnsep}{0.26in}
|
||||
\setlength{\topmargin}{0in}
|
||||
\setlength{\headheight}{0in}
|
||||
\setlength{\headsep}{.5in}
|
||||
|
@ -124,7 +124,7 @@ assumed padding between ORs, and in
|
||||
later designs added padding between onion proxies (users) and ORs
|
||||
\cite{or-ih96,or-jsac98}. Tradeoffs between padding protection
|
||||
and cost were discussed, and \emph{traffic shaping} algorithms were
|
||||
theorized \cite{or-pet00} that provide good security without expensive
|
||||
theorized \cite{or-pet00} to provide good security without expensive
|
||||
padding, but no concrete padding scheme was suggested.
|
||||
Recent research \cite{econymics}
|
||||
and deployment experience \cite{freedom21-security} suggest that this
|
||||
@ -1242,8 +1242,7 @@ points, informs him of her rendezvous point, and then waits for him
|
||||
to connect to the rendezvous point. This extra level of indirection
|
||||
helps Bob's introduction points avoid problems associated with serving
|
||||
unpopular files directly (for example, if Bob serves
|
||||
material that the introduction point's neighbors find objectionable,
|
||||
%XXX neighbors is a technical term
|
||||
material that the introduction point's community finds objectionable,
|
||||
or if Bob's service tends to get attacked by network vandals).
|
||||
The extra level of indirection also allows Bob to respond to some requests
|
||||
and ignore others.
|
||||
@ -1256,9 +1255,7 @@ application integration is described more fully below.
|
||||
\item Bob chooses some introduction points, and advertises them on
|
||||
the DHT. He can add more later.
|
||||
\item Bob builds a circuit to each of his introduction points,
|
||||
and waits. No data is yet transmitted.
|
||||
% XXX what do we mean No data? Bob obviously tells the IP about
|
||||
% his hash-of-public key, auth scheme, etc
|
||||
and waits. No more data is transmitted before the first request.
|
||||
\item Alice learns about Bob's service out of band (perhaps Bob told her,
|
||||
or she found it on a website). She retrieves the details of Bob's
|
||||
service from the DHT.
|
||||
@ -1272,7 +1269,7 @@ application integration is described more fully below.
|
||||
first half of a DH
|
||||
handshake. The introduction point sends the message to Bob.
|
||||
\item If Bob wants to talk to Alice, he builds a circuit to Alice's
|
||||
RP and provides the rendezvous cookie, the second half of the DH
|
||||
RP and sends the rendezvous cookie, the second half of the DH
|
||||
handshake, and a hash of the session
|
||||
key they now share. By the same argument as in
|
||||
Section~\ref{subsubsec:constructing-a-circuit}, Alice knows she
|
||||
@ -1342,13 +1339,13 @@ those users can switch to accessing Bob's service via
|
||||
the Tor rendezvous system.
|
||||
|
||||
Since Bob's introduction points might themselves be subject to DoS he
|
||||
could be faced with a choice between keeping many
|
||||
could have to choose between keeping many
|
||||
introduction connections open or risking such an attack. In this case,
|
||||
similar to the authentication tokens, he can provide selected users
|
||||
he can provide selected users
|
||||
with a current list and/or future schedule of introduction points that
|
||||
are not advertised in the DHT\@. This is most likely to be practical
|
||||
if there is a relatively stable and large group of introduction points
|
||||
generally available. Alternatively, Bob could give secret public keys
|
||||
available. Alternatively, Bob could give secret public keys
|
||||
to selected users for consulting the DHT\@. All of these approaches
|
||||
have the advantage of limiting exposure even when
|
||||
some of the selected high-priority users collude in the DoS\@.
|
||||
@ -1460,11 +1457,11 @@ been shown to be effective against SafeWeb \cite{hintz-pet02}.
|
||||
%possibility that multiple streams are exiting the circuit at
|
||||
%different places concurrently.
|
||||
% XXX How does that help? Roger and I don't know. -NM
|
||||
It may slightly less effective against Tor, since
|
||||
It may be less effective against Tor, since
|
||||
fingerprinting will be limited to
|
||||
the granularity of cells, currently 256 bytes. Further potential
|
||||
defenses include
|
||||
larger cell sizes and/or minimal padding schemes to group websites
|
||||
larger cell sizes and/or padding schemes to group websites
|
||||
into large sets. But this remains an open problem. Link
|
||||
padding or long-range dummies may also make fingerprints harder to
|
||||
detect.\footnote{Note that
|
||||
@ -1681,10 +1678,10 @@ blocking of valid requests, however, he should periodically test the
|
||||
introduction point by sending it introduction requests, and making
|
||||
sure he receives them.
|
||||
|
||||
\emph{Compromise a rendezvous point.} Controlling a rendezvous
|
||||
point gains an attacker no more than controlling any other OR along
|
||||
a circuit, since all data passing through the rendezvous is protected
|
||||
by the session key shared by the client and server.
|
||||
\emph{Compromise a rendezvous point.} A rendezvous
|
||||
point is no more sensitive than any other OR on
|
||||
a circuit, since all data passing through the rendezvous is encrypted
|
||||
with a session key shared by Alice and Bob.
|
||||
|
||||
\Section{Open Questions in Low-latency Anonymity}
|
||||
\label{sec:maintaining-anonymity}
|
||||
@ -1747,8 +1744,8 @@ by batching and re-ordering packets, but it is unclear whether this could
|
||||
improve anonymity without introducing so much latency as to render the
|
||||
network unusable.
|
||||
|
||||
A cascade topology may better defend against traffic confirmation by a
|
||||
large adversary through aggregating users, and making padding and
|
||||
A cascade topology may better defend against traffic confirmation by
|
||||
aggregating users, and making padding and
|
||||
mixing more affordable. Does the hydra topology (many input nodes,
|
||||
few output nodes) work better against some adversaries? Are we going
|
||||
to get a hydra anyway because most nodes will be middleman nodes?
|
||||
@ -1819,11 +1816,11 @@ and possibly better anonymity \cite{econymics}. More nodes means increased
|
||||
scalability, and more users can mean more anonymity. We need to continue
|
||||
examining the incentive structures for participating in Tor.
|
||||
|
||||
\emph{Cover traffic:} Currently Tor avoids cover traffic because its costs
|
||||
\emph{Cover traffic:} Currently Tor omits cover traffic because its costs
|
||||
in performance and bandwidth are clear, whereas its security benefits are
|
||||
not well understood. We must pursue more research on both link-level cover
|
||||
traffic and long-range cover traffic to determine some simple padding
|
||||
schemes that offer provable protection against our chosen adversary.
|
||||
not well understood. We must pursue more research on link-level cover
|
||||
traffic and long-range cover traffic to determine whether some simple padding
|
||||
method offers provable protection against our chosen adversary.
|
||||
|
||||
%%\emph{Offer two relay cell sizes:} Traffic on the Internet tends to be
|
||||
%%large for bulk transfers and small for interactive traffic. One cell
|
||||
@ -1837,10 +1834,9 @@ On the other hand, forward security is weakened because caches
|
||||
constitute a record of retrieved files. We must find the right
|
||||
balance between usability and security.
|
||||
|
||||
\emph{Better directory distribution:} %Directory retrieval presents
|
||||
%a scaling problem, since
|
||||
\emph{Better directory distribution:}
|
||||
Clients currently download a description of
|
||||
the entire network state every 15 minutes. As the state grows larger
|
||||
the entire network every 15 minutes. As the state grows larger
|
||||
and clients more numerous, we may need a solution in which
|
||||
clients receive incremental updates to directory state.
|
||||
More generally, we must find more
|
||||
|
Loading…
Reference in New Issue
Block a user