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

patch the spec somewhat. it's still quite stale.

Browse Source 
svn:r406
This commit is contained in:
Roger Dingledine 2003-08-22 03:34:51 +00:00
parent faf831893d
commit bb1584274c
1 changed files with 16 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
doc/tor-spec.txt
View File

@ -23,7 +23,7 @@ TODO: (very soon)
All numeric values are encoded in network (big-endian) order.
Unless otherwise specified, all symmetric ciphers are 3DES in OFB
Unless otherwise specified, all symmetric ciphers are AES in counter
mode, with an IV of all 0 bytes. Asymmetric ciphers are either RSA
with 1024-bit keys and exponents of 65537, or DH with the safe prime
from rfc2409, section 6.2, whose hex representation is:
@ -34,8 +34,6 @@ TODO: (very soon)
"A637ED6B0BFF5CB6F406B7EDEE386BFB5A899FA5AE9F24117C4B1FE6"
"49286651ECE65381FFFFFFFFFFFFFFFF"
[We will move to AES once we can assume everybody will have it. -RD]
1. System overview
@ -64,7 +62,8 @@ which reveals the downstream node.
The client generates a pair of 16-byte symmetric keys (one
[K_f] for the 'forward' stream from client to server, and one
[K_b] for the 'backward' stream from server to client.
[K_b] for the 'backward' stream from server to client) to be
used for link encryption.
The client then generates a 'Client authentication' message [M]
containing:
@ -72,8 +71,8 @@ which reveals the downstream node.
(If client is an OP)
The number 1 to signify OP handshake [2 bytes]
Maximum bandwidth (bytes/s) [4 bytes]
Forward key [K_f] [16 bytes]
Backward key [K_b] [16 bytes]
Forward link key [K_f] [16 bytes]
Backward link key [K_b] [16 bytes]
[Total: 38 bytes]
(If client is an OR)
@ -94,7 +93,7 @@ which reveals the downstream node.
the 128-byte RSA-encrypted data to the server, and waits for a
reply.
2. The server receives the first handshake
2. The server receives the first handshake:
The OR waits for 128 bytes of data, and decrypts the resulting
data with its private key, checking the PKCS1 padding. If
@ -178,7 +177,7 @@ which reveals the downstream node.
Once the handshake is complete, the two sides send cells
(specified below) to one another. Cells are sent serially,
encrypted with the 3DES-OFB keystream specified by the handshake
encrypted with the AES-CNT keystream specified by the handshake
protocol. Over a connection, communicants encrypt outgoing cells
with the connection's K_f, and decrypt incoming cells with the
connection's K_b.
@ -201,6 +200,8 @@ which reveals the downstream node.
do evil stuff. For instance, if I can guess that a cell is a
TOPIC_COMMAND_BEGIN cell to www.slashdot.org:80 , I can change the
address and port to point to a machine I control. -NM]
[We're going to address this tagging issue with e2e-only hashes.
See TODO file. -RD]
3. Cell Packet format
@ -386,7 +387,7 @@ which reveals the downstream node.
Otherwise, if the OR is not at the OP edge of the circuit (that is,
either an 'exit node' or a non-edge node), it de/encrypts the length
field and the payload with 3DES/OFB, as follows:
field and the payload with AES/CNT, as follows:
'Forward' relay cell (same direction as CREATE):
Use Kf as key; encrypt.
'Back' relay cell (opposite direction from CREATE):
@ -401,13 +402,13 @@ which reveals the downstream node.
handshakes. -RD]
Otherwise, if the data cell is coming from the OP edge of the
circuit, the OP decrypts the length and payload fields with 3DES/OFB as
circuit, the OP decrypts the length and payload fields with AES/CNT as
follows:
OP sends data cell to node R_M:
For I=1...M, decrypt with Kf_I.
Otherwise, if the data cell is arriving at the OP edge if the
circuit, the OP encrypts the length and payload fields with 3DES/OFB as
circuit, the OP encrypts the length and payload fields with AES/CNT as
follows:
OP receives data cell:
For I=N...1,
@ -465,7 +466,6 @@ which reveals the downstream node.
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.
[XXX Mention zlib encoding. -NM]
5.2. Closing streams
@ -511,6 +511,10 @@ which reveals the downstream node.
number of bytes per second on average, though they may use mechanisms
to handle spikes (eg token buckets).
[This isn't true anymore. Each node has a total bandwidth it's willing
to accept from all nodes per second; it ignores negotiated
per-connection bandwidths. -RD]
Communicants rely on TCP's default flow control to push back when they
stop reading, so nodes that don't obey this bandwidth limit can't do
too much damage.