nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-10 13:13:44 +01:00
Code Issues Packages Projects Releases Wiki Activity

begin the process of cleaning/updating the spec

Browse Source 
svn:r973
This commit is contained in:
Roger Dingledine 2004-01-05 05:25:00 +00:00
parent 8bb4f473a9
commit 276dae52b5
1 changed files with 51 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
doc/tor-spec.txt
View File

@ -1,4 +1,4 @@
$Id$
$Id$
Tor Spec
@ -24,7 +24,7 @@ EVEN LATER:
0. Notation:
PK -- a public key.
SK -- a private key
SK -- a private key
K -- a key for a symmetric cypher
a|b -- concatenation of 'a' with 'b'.
@ -45,11 +45,14 @@ EVEN LATER:
1. System overview
Tor is a connection-oriented anonymizing communication service. Users
build a path known as a "virtual circuit" through the network, in which
each node knows its predecessor and successor, but no others. Traffic
flowing down the circuit is unwrapped by a symmetric key at each node,
which reveals the downstream node.
Onion Routing is a distributed overlay network designed to anonymize
low-latency TCP-based applications such as web browsing, secure shell,
and instant messaging. Clients choose a path through the network and
build a ``circuit'', in which each node (or ``onion router'' or ``OR'')
in the path knows its predecessor and successor, but no other nodes in
the circuit. Traffic flowing down the circuit is sent in fixed-size
``cells'', which are unwrapped by a symmetric key at each node (like
the layers of an onion) and relayed downstream.
2. Connections
@ -62,16 +65,16 @@ which reveals the downstream node.
"TLS_DHE_RSA_WITH_AES_128_CBC_SHA". An OR always sends a
self-signed X.509 certificate whose commonName is the server's
nickname, and whose public key is in the server directory.
All parties receiving certificates must confirm that the public
key is as it appears in the server directory, and close the
connection if it is not.
Once a TLS connection is established, the two sides send cells
(specified below) to one another. Cells are sent serially. All
cells are 256 bytes long. Cells may be sent embedded in TLS
cells are 512 bytes long. Cells may be sent embedded in TLS
records of any size or divided across TLS records, but the framing
of TLS records should not leak information about the type or
of TLS records must not leak information about the type or
contents of the cells.
OR-to-OR connections are never deliberately closed. An OP should
@ -87,10 +90,8 @@ which reveals the downstream node.
CircID [2 bytes]
Command [1 byte]
Length [1 byte]
Sequence number (unused, set to 0) [4 bytes]
Payload (padded with 0 bytes) [248 bytes]
[Total size: 256 bytes]
Payload (padded with 0 bytes) [509 bytes]
[Total size: 512 bytes]
The 'Command' field holds one of the following values:
0 -- PADDING (Padding) (See Sec 6.2)
@ -99,26 +100,21 @@ which reveals the downstream node.
3 -- RELAY (End-to-end data) (See Sec 5)
4 -- DESTROY (Stop using a circuit) (See Sec 4)
The interpretation of 'Length' and 'Payload' depend on the type of
the cell.
PADDING: Neither field is used.
CREATE: Length is 144; the payload contains the first phase of the
DH handshake.
CREATED: Length is 128; the payload contains the second phase of
the DH handshake.
RELAY: Length is a value between 8 and 248; the first 'length'
bytes of payload contain useful data.
DESTROY: Neither field is used.
The interpretation of 'Payload' depends on the type of the cell.
PADDING: Unused.
CREATE: Payload contains the handshake challenge.
CREATED: Payload contains the handshake response.
RELAY: Payload contains the relay header and relay body.
DESTROY: Unused.
Unused fields are filled with 0 bytes. The payload is padded with
0 bytes.
The payload is padded with 0 bytes.
PADDING cells are currently used to implement connection
keepalive. ORs and OPs send one another a PADDING cell every few
minutes.
CREATE and DESTROY cells are used to manage circuits; see section
4 below.
CREATE, CREATED, and DESTROY cells are used to manage circuits;
see section 4 below.
RELAY cells are used to send commands and data along a circuit; see
section 5 below.
@ -128,10 +124,11 @@ which reveals the downstream node.
4.1. CREATE and CREATED cells
Users set up circuits incrementally, one hop at a time. To create
a new circuit, users send a CREATE cell to the first node, with the
first half of the DH handshake; that node responds with a CREATED cell
with the second half of the DH handshake. To extend a circuit past
Users set up circuits incrementally, one hop at a time. To create a
new circuit, users send a CREATE cell to the first node, with the
first half of the DH handshake; that node responds with a CREATED
cell with the second half of the DH handshake plus the first 20 bytes
of derivative key data (see section 4.2). To extend a circuit past
the first hop, the user sends an EXTEND relay cell (see section 5)
which instructs the last node in the circuit to send a CREATE cell
to extend the circuit.
@ -139,13 +136,14 @@ which reveals the downstream node.
The payload for a CREATE cell is an 'onion skin', consisting of:
RSA-encrypted data [128 bytes]
Symmetrically-encrypted data [16 bytes]
The RSA-encrypted portion contains:
Symmetric key [16 bytes]
First part of DH data (g^x) [112 bytes]
The symmetrically encrypted portion contains:
Second part of DH data (g^x) [16 bytes]
Second part of DH data (g^x) [16 bytes]
The two parts of the DH data, once decrypted and concatenated, form
The two parts of DH data, once decrypted and concatenated, form
g^x as calculated by the client.
The relay payload for an EXTEND relay cell consists of:
@ -154,23 +152,24 @@ which reveals the downstream node.
Onion skin [144 bytes]
The port and address field denote the IPV4 address and port of the
next onion router in the circuit.
next onion router in the circuit.
4.2. Setting circuit keys
Once the handshake between the OP and an OR is completed, both
servers can now calculate g^xy with ordinary DH. From the base key
material g^xy, they compute two 16 byte keys, called Kf and Kb as
follows. First, the server represents g^xy as a big-endian
unsigned integer. Next, the server computes 40 bytes of key data
as K = SHA1(g^xy | [00]) | SHA1(g^xy | [01]) where "00" is a single
octet whose value is zero, and "01" is a single octet whose value
is one. The first 16 bytes of K form Kf, and the next 16 bytes of
K form Kb.
material g^xy, they compute derivate key material as follows.
First, the server represents g^xy as a big-endian unsigned integer.
Next, the server computes 60 bytes of key data as K = SHA1(g^xy |
[00]) | SHA1(g^xy | [01]) | SHA1(g^xy | [02]) where "00" is a single
octet whose value is zero, "01" is a single octet whose value is
one, etc. The first 20 bytes of K form KH, the next 16 bytes of K
form Kf, and the next 16 bytes of K form Kb.
Kf is used to encrypt the stream of data going from the OP to the
OR, whereas Kb is used to encrypt the stream of data going from the
OR to the OP.
KH is used in the handshake response to demonstrate knowledge of the
computed shared key. Kf is used to encrypt the stream of data going
from the OP to the OR, and Kb is used to encrypt the stream of data
going from the OR to the OP.
4.3. Creating circuits
@ -193,7 +192,7 @@ which reveals the downstream node.
the first onion router.
5. Wait until a CREATED cell is received; finish the handshake
and extract the forward key Kf_1 and the back key Kb_1.
and extract the forward key Kf_1 and the backward key Kb_1.
6. For each subsequent onion router R (R_2 through R_N), extend
the circuit to R.
@ -267,7 +266,7 @@ which reveals the downstream node.
[We'll have to reevaluate this section once we figure out cleaner
circuit/connection killing conventions. -RD]
4.5. Routing data cells
4.5. Routing relay cells
When an OR receives a RELAY cell, it checks the cell's circID and
determines whether it has a corresponding circuit along that
@ -299,7 +298,7 @@ which reveals the downstream node.
circuit, the OP encrypts the length and payload fields with AES/CTR as
follows:
OP receives data cell:
For I=N...1,
For I=N...1,
Encrypt with Kb_I. If the stream ID is a recognized
stream for R_I, or if the stream ID is the signaling
ID (zero), then stop and process the payload.
@ -355,7 +354,7 @@ which reveals the downstream node.
The OP waits for a RELAY_CONNECTED cell before sending any data.
Once a connection has been established, the OP and exit node
package stream data in RELAY_DATA cells, and upon receiving such
cells, echo their contents to the corresponding TCP stream.
cells, echo their contents to the corresponding TCP stream.
Relay RELAY_DROP cells are long-range dummies; upon receiving such
a cell, the OR or OP must drop it.
@ -418,11 +417,11 @@ which reveals the downstream node.
To control a circuit's bandwidth usage, each OR keeps track of
two 'windows', consisting of how many RELAY_DATA cells it is
allowed to package for transmission, and how many RELAY_DATA cells
it is willing to deliver to streams outside the network.
it is willing to deliver to streams outside the network.
Each 'window' value is initially set to 1000 data cells
in each direction (cells that are not data cells do not affect
the window). When an OR is willing to deliver more cells, it sends a
RELAY_SENDME cell towards the OP, with Stream ID zero. When an OR
RELAY_SENDME cell towards the OP, with Stream ID zero. When an OR
receives a RELAY_SENDME cell with stream ID zero, it increments its
packaging window.
@ -430,7 +429,7 @@ which reveals the downstream node.
The OP behaves identically, except that it must track a packaging
window and a delivery window for every OR in the circuit.
An OR or OP sends cells to increment its delivery window when the
corresponding window value falls under some threshold (900).