diff options
author | Roger Dingledine <arma@torproject.org> | 2003-08-22 03:34:51 +0000 |
---|---|---|
committer | Roger Dingledine <arma@torproject.org> | 2003-08-22 03:34:51 +0000 |
commit | bb1584274cb07110020d24df5b8fc623ebc1d23d (patch) | |
tree | 51668efc91b9cd6222a5ad82d7ba3e0884ea13c7 /doc | |
parent | faf831893d90dc4de776d086f7a5ac21b5a8139b (diff) | |
download | tor-bb1584274cb07110020d24df5b8fc623ebc1d23d.tar tor-bb1584274cb07110020d24df5b8fc623ebc1d23d.tar.gz |
patch the spec somewhat. it's still quite stale.
svn:r406
Diffstat (limited to 'doc')
-rw-r--r-- | doc/tor-spec.txt | 28 |
1 files changed, 16 insertions, 12 deletions
diff --git a/doc/tor-spec.txt b/doc/tor-spec.txt index 2b834b343..7a69c0310 100644 --- a/doc/tor-spec.txt +++ b/doc/tor-spec.txt @@ -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. |