mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 13:13:44 +01:00
Edits to recent edits.
svn:r739
This commit is contained in:
parent
3a0d3b7c89
commit
2dcafa8527
@ -401,12 +401,10 @@ it is a security requirement \cite{econymics,back01}. Tor should
|
||||
therefore not
|
||||
require modifying applications; should not introduce prohibitive delays;
|
||||
and should require the user to make as few configuration decisions
|
||||
as possible.
|
||||
Platform support is also an important factor in both usability and
|
||||
deployability. Tor currently runs on linux, Windows, and assorted
|
||||
BSDs (including MacOS X).
|
||||
%XXX Did I forget any? We need to say this somewhere. It's a big deal
|
||||
%XXX so should it instead be at the beginning and/or end? -PS
|
||||
as possible. Finally, Tor should be easily implemented on all commonly used
|
||||
platforms; we cannot require users to change their operating system in order
|
||||
to be anonymous. (The current Tor implementation runs on Windows and
|
||||
assorted Unix-clones including Linux, FreeBSD, and MacOS X.)
|
||||
|
||||
\textbf{Flexibility:} The protocol must be flexible and well-specified,
|
||||
so that it can serve as a test-bed for future research in low-latency
|
||||
@ -633,7 +631,7 @@ seven bytes, plus one byte for the command.
|
||||
|
||||
%XXXX Discuss what happens with circIDs here.
|
||||
|
||||
A User's OP constructs a circuit incrementally, negotiating a
|
||||
A user's OP constructs a circuit incrementally, negotiating a
|
||||
symmetric key with each OR on the circuit, one hop at a time. To begin
|
||||
creating a new circuit, the OP (call her Alice) sends a
|
||||
\emph{create} cell to the first node in her chosen path. This cell's
|
||||
@ -1344,15 +1342,16 @@ design withstands them.
|
||||
end-to-end timing correlations. An attacker watching patterns of
|
||||
traffic at the initiator and the responder will be
|
||||
able to confirm the correspondence with high probability. The
|
||||
greatest protection currently against such confirmation is to hide
|
||||
greatest protection currently available against such confirmation is to hide
|
||||
the connection between the onion proxy and the first Tor node,
|
||||
either because it is local or behind a firewall. This approach
|
||||
by running the onion proxy locally or
|
||||
behind a firewall. This approach
|
||||
requires an observer to separate traffic originating at the onion
|
||||
router from traffic passes through it; but because we do not mix
|
||||
router from traffic passing through it; but because we do not mix
|
||||
or pad, this does not provide much defense.
|
||||
|
||||
\item \emph{End-to-end Size correlation.} Simple packet counting
|
||||
without timing consideration will also be effective in confirming
|
||||
without timing correlation will also be effective in confirming
|
||||
endpoints of a stream. However, even without padding, we have some
|
||||
limited protection: the leaky pipe topology means different numbers
|
||||
of packets may enter one end of a circuit than exit at the other.
|
||||
@ -1841,6 +1840,7 @@ issues remaining to be ironed out. In particular:
|
||||
cached at the ORs to avoid high loads on the directory servers.
|
||||
% XXX this is a design paper, not an implementation paper. the design
|
||||
% says that they're already cached at the ORs. Agree/disagree?
|
||||
% XXX Agree. -NM
|
||||
\item \emph{Implementing location-hidden servers:} While
|
||||
Section~\ref{sec:rendezvous} describes a design for rendezvous
|
||||
points and location-hidden servers, these feature has not yet been
|
||||
|
Loading…
Reference in New Issue
Block a user