[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [tor-design-2012/master] Revise "tor design" up through "opening and closing streams"
commit 8be9b3c21782665c0edebab101e4f3e60d2aba2e
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date: Fri Nov 9 21:38:58 2012 -0500
Revise "tor design" up through "opening and closing streams"
---
tor-design-2012.tex | 72 ++++++++++++++++++++++++--------------------------
1 files changed, 35 insertions(+), 37 deletions(-)
diff --git a/tor-design-2012.tex b/tor-design-2012.tex
index e7a662b..e09a95d 100644
--- a/tor-design-2012.tex
+++ b/tor-design-2012.tex
@@ -619,17 +619,15 @@ well the Tor design defends against each of these attacks.
The Tor network is an overlay network; each onion router (OR)
runs as a normal user-level process without any special
-privileges. Each onion router maintains a TLS~\cite{TLS}
-connection to onion routers to which it has been recently
+privileges. Each onion router maintains TLS~\cite{TLS}
+connections to other onion routers it has been recently
communicating with. Each user runs local software called an
onion proxy (OP) to fetch directories, establish circuits across
the network, and handle connections from user applications.
These onion proxies accept TCP streams and multiplex them across
the circuits. The onion router on the other side of the circuit
connects to the requested destinations and relays data.
-% Is our topology actually clique any longer? -NM Perhaps
-% I've changed this to indicate the fact that unused links are
-% timed out -SJM
+
% mention that the OR and the OP are the same software. -NM
Each onion router maintains a long-term identity key and a
@@ -642,9 +640,6 @@ and negotiate ephemeral keys. The TLS protocol also establishes
a short-term link key when communicating between ORs. Short-term
keys are rotated periodically and independently, to limit the
impact of key compromise.
-% Clarify the role of the link keys. -NM
-% XXXX I hope somewhere in this paperwe talk more about the link protocol, so
-% we can say more abotu the v2 and v3 versions of it. -NM
Section~\ref{subsec:cells} presents the fixed-size \emph{cells}
that are the unit of most communication in Tor. We describe in
@@ -655,6 +650,7 @@ integrity checking in Section~\ref{subsec:integrity-checking},
and resource limiting in Section~\ref{subsec:rate-limit}.
Finally, Section~\ref{subsec:congestion} talks about congestion
control and fairness issues.
+% XXXX add more sections once we have a full list.x
\subsection{Cells}
\label{subsec:cells}
@@ -665,7 +661,9 @@ data on the connection with perfect forward secrecy, and
prevents an attacker from modifying data on the wire or
impersonating an OR.
-Most traffic passes along these connections in fixed-size cells.
+Most traffic passes along these connections in fixed-size
+cells.\footnote{A few cell types, notably those used for
+ connection establishment, are variable-sized.}
Each fixed-size cell is 512 bytes, and consists of a header and a
payload. The header includes a circuit identifier (circID) that
specifies which circuit the cell refers to (many circuits can be
@@ -700,36 +698,34 @@ link-protocol negotiation); \emph{vpadding} (variable length
padding); and \emph{certs}, \emph{auth\_challenge},
\emph{authenticate}, and \emph{authorize} (used for OR-OR and
OP-OR authentication).
-% Add: CREATE_FAST, CREATED_FAST, NETINFO, RELAY_EARLY,
-% VERSIONS, VPADDING, CERTS, AUTH_CHALLENGE, AUTHENTICATE,
-% AUTHORIZE. -NM
-% Believed done -SJM
Relay cells have an additional header (the relay header) at the
front of the payload, containing a streamID (stream identifier:
many streams can be multiplexed over a circuit); an end-to-end
-checksum for integrity checking; the length of the relay
+truncated digest for integrity checking; the length of the relay
payload; and a relay command.
-% We shouldn't call the SHA1 field a checksum. -NM
The entire contents of the relay
header and the relay cell payload are encrypted or decrypted
together as the relay cell moves along the circuit, using the
128-bit AES cipher in counter mode to generate a cipher stream.
The relay commands are: \emph{relay data} (for data flowing down
-the stream), \emph{relay begin} (to open a stream), \emph{relay
+the stream), \emph{relay begin} (to open a stream),
+\emph{relay begin dir} (to open a local stream for directory
+information), \emph{relay
end} (to close a stream cleanly), \emph{relay teardown} (to
close a broken stream), \emph{relay connected} (to notify the OP
that a relay begin has succeeded), \emph{relay extend} and
\emph{relay extended} (to extend the circuit by a hop, and to
acknowledge), \emph{relay truncate} and \emph{relay truncated}
(to tear down only part of the circuit, and to acknowledge),
-\emph{relay sendme} (used for congestion control), and
+\emph{relay sendme} (used for congestion control),
+\empl{relay resolve} and \emph{relay resolved} (used for
+anonymous DNS),
+and
\emph{relay drop} (used to implement long-range dummies). We
give a visual overview of cell structure plus the details of
relay cell structure, and then describe each of these cell types
and commands in more detail below.
-% Add: RELAY_RESOLVE, RELAY_RESOLVED, and RELAY_BEGIN_DIR. Mention that there
-% are more used for hidden services. -NM
%\begin{figure}[h]
%\unitlength=1cm
@@ -802,8 +798,7 @@ nonce, and a MAC using the TLS master secret as its key, of
the TLS handshake's client\_random and server\_random
parameters.
-% Justify the above. -MN
-
+% Justify the above. -NM
\subsection{Circuits and streams}
\label{subsec:circuits}
@@ -881,9 +876,9 @@ harming user experience.
\noindent{\large\bf Constructing a circuit}\label{subsubsec:constructing-a-circuit}\\
%\subsubsection{Constructing a circuit}
A user's OP constructs circuits incrementally, negotiating a
-symmetric key with each OR on the circuit, one hop at a time.
-% "And using each partially created circuit to communicate with the
-% next hop in turn" - NM
+symmetric key with each OR on the circuit, one hop at a time,
+and using each partially created circuit to communicate with the
+next hop.
To
begin creating a new circuit, the OP (call her Alice) sends a
\emph{create} cell to the first node in her chosen path (call
@@ -896,10 +891,12 @@ negotiated key $K=g^{xy}$.
Once the circuit has been established, Alice and Bob can send
one another relay cells encrypted with the negotiated
-key.\footnote{Actually, the negotiated key is used to derive two
- symmetric keys: one for each direction.} More detail is given
+key.\footnote{Actually, the negotiated key is used to derive four
+ symmetric keys: one for each direction for AES, and one in
+ each direction for integrity. To generate enough key
+ material, Tor uses an ad hoc key derivation function where
+ K is expanded to $H(K | [00]) | H(K | [01]) | ...$ } More detail is given
in the next section.
-% We should mention the KDF -NM
To extend the circuit further, Alice sends a \emph{relay extend}
cell to Bob, specifying the address of the next OR (call her
@@ -942,11 +939,12 @@ is too small to hold both a public key and a
signature. Preliminary analysis with the NRL protocol
analyzer~\cite{meadows96} shows this protocol to be secure
(including perfect forward secrecy) under the traditional
-Dolev-Yao model.
-% Mention Ian's TAP paper, and mention its finding that our actual
-% implementation of the protocol above is a little fraught.
-% Maaaybe mention ACE and ntor handshakes as future directions
-% here; if not, mention them in future work. -NM
+Dolev-Yao model. In practice, since the most data that can
+be encrypted with padded RSA-1024 is less than the size
+needed to hold an DH-1024 value, we need to use hybrid
+encryption. Tor's original hybrid encryption approach here
+was somewhat poorly designed, but turns out to be secure
+anyway; \cite{TAP} has more details.
As an optimization, Alice client may sent an \emph{create\_fast} cell in
place of her first \emph{create} cell: instead of sending an encrypted $g^x$
@@ -967,17 +965,15 @@ session key for that circuit. If the cell is headed away from
Alice the OR then checks whether the decrypted cell has a valid
digest (as an optimization, the first two bytes of the integrity
check are zero, so in most cases we can avoid computing the
-hash). If valid, it accepts the relay cell and processes it as
+hash). If the digest is valid
+(See~\ref{subsec:integrity-checking}, it accepts the relay
+cell and processes it as
described below. Otherwise, the OR looks up the circID and OR
for the next step in the circuit, replaces the circID as
appropriate, and sends the decrypted relay cell to the next OR.
(If the OR at the end of the circuit receives an unrecognized
relay cell, an error has occurred, and the circuit is torn
down.)
-% Do we anywhere mention that the digest is taken over all plantexts so far,
-% not just the current plaintext? -NM
-% Ah yes, in ``Integrity checking in streams'' below. It should get a
-% fwd-reference here. -NM
OPs treat incoming relay cells similarly: they iteratively
unwrap the relay header and payload with the session keys shared
@@ -2213,6 +2209,8 @@ more approaches to limiting abuse, and understand why most
people don't bother using privacy systems.
% Still future work. Be less sure it's a good idea. -NM
+% Mention ntor, ace, etc
+
\emph{Cover traffic:} Currently Tor omits cover traffic---its
costs in performance and bandwidth are clear but its security
benefits are not well understood. We must pursue more research
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits