mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 21:23:58 +01:00
Add design goals section
svn:r646
This commit is contained in:
parent
24536a65f3
commit
53dca60b13
@ -409,8 +409,6 @@ OR network. Even a firewall-to-firewall connection is exposed
|
|||||||
if, as assumed above, our goal is to hide which local-COR is talking to
|
if, as assumed above, our goal is to hide which local-COR is talking to
|
||||||
which local-COR.
|
which local-COR.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
\SubSection{Known attacks against low-latency anonymity systems}
|
\SubSection{Known attacks against low-latency anonymity systems}
|
||||||
\label{subsec:known-attacks}
|
\label{subsec:known-attacks}
|
||||||
|
|
||||||
@ -438,7 +436,77 @@ tagging attacks
|
|||||||
\Section{Design goals and assumptions}
|
\Section{Design goals and assumptions}
|
||||||
\label{sec:assumptions}
|
\label{sec:assumptions}
|
||||||
|
|
||||||
[XXX Perhaps the threat model belongs here.]
|
\subsection{Goals}
|
||||||
|
% Are these really our goals? ;) -NM
|
||||||
|
Like other low-latency anonymity designs, Tor seeks to frustrate
|
||||||
|
attackers from linking communication partners, or from linking
|
||||||
|
multiple communications to or from a single point. Within this
|
||||||
|
overriding goal, however, several design considerations have directed
|
||||||
|
Tor's evolution.
|
||||||
|
|
||||||
|
First, we have tried to build a {\bf deployable} system. [XXX why?]
|
||||||
|
This requirement precludes designs that are expensive to run (for
|
||||||
|
example, by requiring more bandwidth than volunteers are easy to
|
||||||
|
provide); designs that place a heavy liability burden on operators
|
||||||
|
(for example, by allowing attackers to implicate operators in illegal
|
||||||
|
activities); and designs that are difficult or expensive to implement
|
||||||
|
(for example, by requiring kernel patches to many operating systems,
|
||||||
|
or ).
|
||||||
|
|
||||||
|
Second, the system must be {\bf usable}. A hard-to-use system has
|
||||||
|
fewer users---and because anonymity systems hide users among users, a
|
||||||
|
system with fewer users provides less anonymity. Thus, usability is
|
||||||
|
not only a convenience, but is a security requirement for anonymity
|
||||||
|
systems.
|
||||||
|
|
||||||
|
Third, the protocol must be {\bf extensible}, so that it can serve as
|
||||||
|
a test-bed for future research in low-latency anonymity systems.
|
||||||
|
(Note that while an extensible protocol benefits researchers, there is
|
||||||
|
a danger that differing choices of extensions will render users
|
||||||
|
distinguishable. Thus, implementations should not permit different
|
||||||
|
protocol extensions to coexist in a single deployed network.)
|
||||||
|
|
||||||
|
The protocol's design and security parameters must be {\bf
|
||||||
|
conservative}. Additional features impose implementation and
|
||||||
|
complexity costs. [XXX Say that we don't want to try to come up with
|
||||||
|
speculative solutions to problems we don't KNOW how to solve? -NM]
|
||||||
|
|
||||||
|
[XXX mention something about robustness? But we really aren't that
|
||||||
|
robust. We just assume that tunneled protocols tolerate connection
|
||||||
|
loss. -NM]
|
||||||
|
|
||||||
|
\subsection{Non-goals}
|
||||||
|
In favoring conservative, deployable designs, we have explicitly
|
||||||
|
deferred a number of goals---not because they are not desirable in
|
||||||
|
anonymity systems---but because solving them is either solved
|
||||||
|
elsewhere, or an area of active research without a generally accepted
|
||||||
|
solution.
|
||||||
|
|
||||||
|
Unlike Tarzan or Morphmix, Tor does not attempt to scale to completely
|
||||||
|
decentralized peer-to-peer environments with thousands of short-lived
|
||||||
|
servers.
|
||||||
|
|
||||||
|
Tor does not claim to provide a definitive solution to end-to-end
|
||||||
|
timing or intersection attacks for users who do not run their own
|
||||||
|
Onion Routers.
|
||||||
|
|
||||||
|
Tor does not provide ``protocol normalization'' like the Anonymizer,
|
||||||
|
Privoxy, or XXX. In order to provide client indistinguishibility for
|
||||||
|
complex and variable protocols such as HTTP, Tor must be layered with
|
||||||
|
a proxy such as Privoxy or XXX. Similarly, Tor does not currently
|
||||||
|
integrate tunneling for non-stream-based protocols; this too must be
|
||||||
|
provided by an external service.
|
||||||
|
|
||||||
|
Tor is not steganographic. It doesn't try to conceal which users are
|
||||||
|
sending or receiving communications via Tor.
|
||||||
|
|
||||||
|
\subsection{Assumptions}
|
||||||
|
- Threat model
|
||||||
|
- Mostly reliable nodes: not trusted.
|
||||||
|
- Small group of trusted dirserv ops
|
||||||
|
- Many users of diff bandwidth come and go.
|
||||||
|
|
||||||
|
[XXX what else?]
|
||||||
|
|
||||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user