mirrors/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2025-02-23 14:40:51 +01:00
Code Issues Projects Releases Wiki Activity

Specify CREATE_FAST more fully.

Browse source 
svn:r5529
This commit is contained in:
Nick Mathewson 2005-12-08 17:36:05 +00:00
parent 617f71e4ba
commit 25303172b8
1 changed files with 22 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
doc/tor-spec.txt
View file

@ -194,9 +194,9 @@ when do we rotate which keys (tls, link, etc)?
The port and address field denote the IPV4 address and port of the next
onion router in the circuit; the public key hash is the SHA1 hash of the
PKCS#1 ASN1 encoding of the next onion router's identity (signing) key.
[XXX please describe why we have this hash. my first guess is that this
way we can notice that we're already connected to this guy even if he's
connected at a different place. anything else? -RD]
(Including this hash allows the extending OR verify that it is indeed
connected to the correct target OR, and prevents certain man-in-the-middle
attacks.)
The payload for a CREATED cell, or the relay payload for an
EXTENDED cell, contains:
@ -212,6 +212,8 @@ connected at a different place. anything else? -RD]
Public keys are compared numerically by modulus.
As usual with DH, x and y MUST be generated randomly.
(Older versions of Tor compared OR nicknames, and did it in a broken and
unreliable way. To support versions of Tor earlier than 0.0.9pre6,
implementations should notice when the other side of a connection is
@ -223,7 +225,7 @@ connected at a different place. anything else? -RD]
established the OR's identity and negotiated a secret key using TLS.
Because of this, it is not always necessary for the OP to perform the
public key operations to create a circuit. In this case, the
OP SHOULD send a CREATE_FAST cell instead of a CREATE cell for the first
OP MAY send a CREATE_FAST cell instead of a CREATE cell for the first
hop only. The OR responds with a CREATED_FAST cell, and the circuit is
created.
@ -234,14 +236,16 @@ connected at a different place. anything else? -RD]
A CREATED_FAST cell contains:
Key material (Y) [20 bytes]
Derivative key data [20 bytes]
Derivative key data [20 bytes] (See 4.2 below)
The values of X and Y must be generated randomly.
[Versions of Tor before 0.1.0.6-rc did not support these cell types;
clients should not send CREATE_FAST cells to older Tor servers.]
4.2. Setting circuit keys
Once the handshake between the OP and an OR is completed, both servers can
Once the handshake between the OP and an OR is completed, both can
now calculate g^xy with ordinary DH. Before computing g^xy, both client
and server MUST verify that the received g^x or g^y value is not degenerate;
that is, it must be strictly greater than 1 and strictly less than p-1
@ -252,15 +256,20 @@ connected at a different place. anything else? -RD]
discarded, an attacker can substitute the server's CREATED cell's g^y with
0 or 1, thus creating a known g^xy and impersonating the server.)
(The mainline Tor implementation, in the 0.1.1.x-alpha series, also
discarded all g^x values that are less than 2^24, that are greater than
p-2^24, or that have more than 1024-16 identical bits. This serves no
useful purpose, and will probably stop soon.)
(The mainline Tor implementation, in the 0.1.1.x-alpha series, discarded
all g^x values less than 2^24, greater than p-2^24, or having more than
1024-16 identical bits. This served no useful purpose, and we stopped.)
If CREATE or EXTEND is used to extend a circuit, the client and server
base their key material on K0=g^xy, represented as a big-endian unsigned
integer.
If CREATE_FAST is used, the client and server base their key material on
K0=X|Y.
From the base key material g^xy, they compute derivative key material as
follows. First, the server represents g^xy as a big-endian unsigned
integer. Next, the server computes 100 bytes of key data as K = SHA1(g^xy
| [00]) | SHA1(g^xy | [01]) | ... SHA1(g^xy | [04]) where "00" is a single
follows. Next, the server computes 100 bytes of key data as K = SHA1(K0
| [00]) | SHA1(K0 | [01]) | ... SHA1(K0 | [04]) 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, bytes 21-40 form the forward digest Df,
41-60 form the backward digest Db, 61-76 form Kf, and 77-92 form Kb.