[or-cvs] Specify CREATE_FAST more fully.

[nickm@xxxxxxxx (Nick Mathewson)]

Update of /home/or/cvsroot/tor/doc
In directory moria:/tmp/cvs-serv7620/doc

Modified Files:
	tor-spec.txt 
Log Message:
Specify CREATE_FAST more fully.

Index: tor-spec.txt
===================================================================
RCS file: /home/or/cvsroot/tor/doc/tor-spec.txt,v
retrieving revision 1.102
retrieving revision 1.103
diff -u -d -r1.102 -r1.103
--- tor-spec.txt	17 Nov 2005 18:14:29 -0000	1.102
+++ tor-spec.txt	8 Dec 2005 17:36:05 -0000	1.103
@@ -194,9 +194,9 @@
    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 @@
 
    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 @@
    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 @@
    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 @@
    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.