[or-cvs] mention the digest seeds for circuit-level integrity checking

Roger Dingledine arma at seul.org
Wed May 5 06:53:46 UTC 2004


Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc

Modified Files:
	tor-spec.txt 
Log Message:
mention the digest seeds for circuit-level integrity checking

unused portions of relay payloads are nul-padded, not filled with
random bytes.


Index: tor-spec.txt
===================================================================
RCS file: /home/or/cvsroot/doc/tor-spec.txt,v
retrieving revision 1.53
retrieving revision 1.54
diff -u -d -r1.53 -r1.54
--- tor-spec.txt	28 Apr 2004 20:01:54 -0000	1.53
+++ tor-spec.txt	5 May 2004 06:53:44 -0000	1.54
@@ -1,4 +1,4 @@
-sw$Id$
+$Id$
 
 Tor Spec
 
@@ -125,7 +125,8 @@
    The payload is padded with 0 bytes.
 
    PADDING cells are currently used to implement connection keepalive.
-   ORs and OPs send one another a PADDING cell every few minutes.
+   If there is no other traffic, ORs and OPs send one another a PADDING
+   cell every few minutes.
 
    CREATE, CREATED, and DESTROY cells are used to manage circuits;
    see section 4 below.
@@ -192,16 +193,19 @@
    servers can now calculate g^xy with ordinary DH.  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 60 bytes of key data as K = SHA1(g^xy |
-   [00]) | SHA1(g^xy | [01]) | SHA1(g^xy | [02]) 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, the next 16 bytes of K
-   form Kf, and the next 16 bytes of K form Kb.
+   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 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.
 
    KH is used in the handshake response to demonstrate knowledge of the
-   computed shared key. Kf is used to encrypt the stream of data going
-   from the OP to the OR, and Kb is used to encrypt the stream of data
-   going from the OR to the OP.
+   computed shared key. Df is used to seed the integrity-checking hash
+   for the stream of data going from the OP to the OR, and Db seeds the
+   integrity-checking hash for the data stream from the OR to the OP. Kf
+   is used to encrypt the stream of data going from the OP to the OR, and
+   Kb is used to encrypt the stream of data going from the OR to the OP.
 
 4.3. Creating circuits
 
@@ -232,10 +236,9 @@
    To extend the circuit by a single onion router R_M, the OP performs
    these steps:
 
-      1. Create an onion skin, encrypting the RSA-encrypted part with
-         R's public key.
+      1. Create an onion skin, encrypted to R_M's public key.
 
-      2. Encrypt and send the onion skin in a relay EXTEND cell along
+      2. Send the onion skin in a relay EXTEND cell along
          the circuit (see section 5).
 
       3. When a relay EXTENDED cell is received, verify KH, and
@@ -341,7 +344,7 @@
    The payload of each unencrypted RELAY cell consists of:
          Relay command           [1 byte]
          'Recognized'            [2 bytes]
-         StreamID               [2 bytes]
+         StreamID                [2 bytes]
          Digest                  [4 bytes]
          Length                  [2 bytes]
          Data                    [498 bytes]
@@ -358,10 +361,12 @@
          9 -- RELAY_TRUNCATED
         10 -- RELAY_DROP
 
-   The 'Recognized' field in any unencrypted relay payload is always set
-   to zero; the 'digest' field is computed as the first four bytes of a
-   SHA-1 digest of the rest of the RELAY cell's payload, taken with the
-   digest field set to zero.
+   The 'Recognized' field in any unencrypted relay payload is always
+   set to zero; the 'digest' field is computed as the first four bytes
+   of the running SHA-1 digest of all the bytes that have travelled
+   over this circuit, seeded from Df or Db respectively (obtained in
+   section 4.2 above), and including this RELAY cell's entire payload
+   (taken with the digest field set to zero).
 
    When the 'recognized' field of a RELAY cell is zero, and the digest
    is correct, the cell is considered "recognized" for the purposes of
@@ -373,8 +378,8 @@
    stream use a StreamID of zero.
 
    The 'Length' field of a relay cell contains the number of bytes in
-   the relay payload which contain real payload data.  The remainder of
-   the payload is padded with random bytes.
+   the relay payload which contain real payload data. The remainder of
+   the payload is padded with NUL bytes.
 
 5.2. Opening streams and transferring data
 
@@ -390,6 +395,7 @@
    dotted-quad format; and where PORT is encoded in decimal.
 
    [What is the [00] for? -NM]
+   [It's so the payload is easy to parse out with string funcs -RD]
 
    Upon receiving this cell, the exit node resolves the address as
    necessary, and opens a new TCP connection to the target port.  If the



More information about the tor-commits mailing list