diff options
author | Nick Mathewson <nickm@torproject.org> | 2003-03-19 21:47:18 +0000 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2003-03-19 21:47:18 +0000 |
commit | 7f7417cd299b7f8fd7f696f34183cbd6286454cf (patch) | |
tree | 68f57e8139f1384e24f3d756b101f5d7fb59db19 | |
parent | 4631f3dcdf43f21257e2081e6a42fdd841a6f878 (diff) | |
download | tor-7f7417cd299b7f8fd7f696f34183cbd6286454cf.tar.gz tor-7f7417cd299b7f8fd7f696f34183cbd6286454cf.zip |
Fix bug in client_send_auth
svn:r203
-rw-r--r-- | doc/tor-spec.txt | 20 | ||||
-rw-r--r-- | src/or/connection_or.c | 2 |
2 files changed, 12 insertions, 10 deletions
diff --git a/doc/tor-spec.txt b/doc/tor-spec.txt index 268fa6fd42..9d35949aae 100644 --- a/doc/tor-spec.txt +++ b/doc/tor-spec.txt @@ -63,10 +63,10 @@ which reveals the downstream node. The client's published port [2 bytes] The server's published IPV4 address [4 bytes] The server's published port [2 bytes] - The forward key (K_f) [8 bytes] - The backward key (K_f) [8 bytes] + The forward key (K_f) [16 bytes] + The backward key (K_f) [16 bytes] The maximum bandwidth (bytes/s) [4 bytes] - [Total: 36 bytes] + [Total: 48 bytes] The client then RSA-encrypts the message with the server's public key, and PKCS1 padding to given an encrypted message @@ -102,9 +102,9 @@ which reveals the downstream node. The server then creates a server authentication message[M2] as follows: - Modified client authentication [32 bytes] + Modified client authentication [48 bytes] A random nonce [N] [8 bytes] - [Total: 40 bytes] + [Total: 56 bytes] The client authentication is generated from M by replacing the client's preferred bandwidth [B_c] with the server's preferred bandwidth [B_s], if B_s < B_c. @@ -167,9 +167,9 @@ which reveals the downstream node. The OP generates a message [M] in the following format: Maximum bandwidth (bytes/s) [4 bytes] - Forward key [K_f] [8 bytes] - Backward key [K_b] [8 bytes] - [Total: 20 bytes] + Forward key [K_f] [16 bytes] + Backward key [K_b] [16 bytes] + [Total: 32 bytes] The OP encrypts M with the OR's public key and PKCS1 padding, opens a TCP connection to the OR's TCP port, and sends the @@ -196,7 +196,7 @@ which reveals the downstream node. Once the handshake is complete, the ORs or OR and OP send cells (specified below) to one another. Cells are sent serially, - encrypted with the DES-OFB keystream specified by the handshake + encrypted with the 3DES-OFB 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. @@ -287,6 +287,7 @@ which reveals the downstream node. 0: Identity 1: Single DES in OFB 2: RC4 + 3: Triple DES in OFB The port and address field denote the IPV4 address and port of the next onion router in the circuit, or are set to 0 for the @@ -462,6 +463,7 @@ which reveals the downstream node. Once a connection has been established, the OP and exit node package stream data in TOPIC_DATA cells, and upon receiving such cells, echo their contents to the corresponding TCP stream. + [XXX Mention zlib encoding. -NM] When one side of the TCP stream is closed, the corresponding edge node sends a TOPIC_END cell along the circuit; upon receiving a diff --git a/src/or/connection_or.c b/src/or/connection_or.c index aca9e746e0..28e28b3c37 100644 --- a/src/or/connection_or.c +++ b/src/or/connection_or.c @@ -628,7 +628,7 @@ int or_handshake_server_process_auth(connection_t *conn) { /* generate message */ memcpy(buf+48,conn->nonce,8); /* append the nonce to the end of the message */ - *(uint32_t *)(buf+28) = htonl(conn->bandwidth); /* send max link utilisation */ + *(uint32_t *)(buf+44) = htonl(conn->bandwidth); /* send max link utilisation */ /* encrypt message */ retval = crypto_pk_public_encrypt(conn->pkey, buf, 56, cipher,RSA_PKCS1_PADDING); |