[or-cvs] r12027: Apply clarifications and comments from Karsten to rend-spec, (in tor/trunk: . doc/spec)

nickm at seul.org nickm at seul.org
Thu Oct 18 18:15:01 UTC 2007


Author: nickm
Date: 2007-10-18 14:15:01 -0400 (Thu, 18 Oct 2007)
New Revision: 12027

Modified:
   tor/trunk/
   tor/trunk/doc/spec/rend-spec.txt
Log:
 r15921 at catbus:  nickm | 2007-10-18 11:16:38 -0400
 Apply clarifications and comments from Karsten to rend-spec, with my own clarifications and comments.



Property changes on: tor/trunk
___________________________________________________________________
 svk:merge ticket from /tor/trunk [r15921] on 8246c3cf-6607-4228-993b-4d95d33730f1

Modified: tor/trunk/doc/spec/rend-spec.txt
===================================================================
--- tor/trunk/doc/spec/rend-spec.txt	2007-10-18 17:41:34 UTC (rev 12026)
+++ tor/trunk/doc/spec/rend-spec.txt	2007-10-18 18:15:01 UTC (rev 12027)
@@ -146,21 +146,21 @@
     to do that if he previously advertised some introduction points,
     and now he doesn't have any. -RD]
 
-   The format of a "V2" descriptor, that will probably used at some time in
-   the future, is as follows:
+   The format of a "V2" descriptor, that will probably be used at some time
+   in the future, is as follows:
 
      "rendezvous-service-descriptor" descriptor-id NL
 
        [At start, exactly once]
 
        Indicates the beginning of the descriptor. "descriptor-id" is a
-       temporary identifier of 160 bits formatted as 32 base32 chars that
-       can only be calculated by the hidden service and its clients,
-       i.e. by everyone who is aware of a "secret-cookie". (Further,
-       everyone can verify that this "descriptor-id" belongs to the rest
-       of the descriptor, even without knowing "secret-cookie", as
-       described below.) The "descriptor-id" is calculated by performing
-       the following operation:
+       periodically changing identifier of 160 bits formatted as 32 base32
+       chars that is calculated by the hidden service and its clients. If
+       the optional "secret-cookie" is used, this "descriptor-id" cannot be
+       computed by anyone else. (Everyone can verify that this
+       "descriptor-id" belongs to the rest of the descriptor, even without
+       knowing the optional "secret-cookie", as described below.) The
+       "descriptor-id" is calculated by performing the following operation:
 
          descriptor-id =
              H(permanent-id | H(time-period | secret-cookie | replica))
@@ -171,19 +171,26 @@
 
          permanent-id = H(public-key)[:10]
 
-       "h(time-period, cookie, replica)" is the secret id part that is
+       "H(time-period | secret-cookie | replica)" is the (possibly secret)
+       id part that is
        necessary to verify that the hidden service is the true originator
        of this descriptor. It can only be created by the hidden service
        and its clients, but the "signature" below can only be created by
        the service.
 
-       "cookie" is a secret password of 120 bits that is shared between the
-       hidden service provider and its clients.
-        [XXXX Why 120? -NM]
+       "secret-cookie" is an optional secret password of 128 bits that is
+       shared between the hidden service provider and its clients.
 
        "replica" denotes the number of the non-consecutive replica.
-        [XXXX What does this mean? -NM]
 
+        (Each descriptor is replicated on a number of _consecutive_ nodes
+         in the identifier ring by making every storing node responsible
+         for the identifier intervals starting from its 3rd predecessor's
+         ID to its own ID. In addition to that, every service publishes
+         multiple descriptors with different descriptor IDs in order to
+         distribute them to different places on the ring. Therefore,
+         "replica" chooses one of the _non-consecutive_ replicas. -KL)
+
        The "time-period" changes periodically depending on the global time and
        as a function of "permanent-id". The current value for "time-period" can
        be calculated using the following formula:
@@ -233,22 +240,23 @@
 
        [Exactly once]
 
-       A bitmask of allowed rendezvous protocols.
-          [XXXX what do the numbers this mean? And why a bitmask??? -NM]
+       A comma-separated list of recognized and permitted version numbers
+       for use in INTRODUCE cells; these versions are described in section
+       1.8 below.
 
      "introduction-points" NL encrypted-string
 
        [At most once]
 
-       A list of introduction points that is encrypted with AES in CTR mode
-       with a random initialization vector of 128 bits that is written to
-       the beginning of the encrypted string, and the secret key "cookie",
-       that is 120 bits long and padded with zeros to be 128 bits long.
-        [XXXX again, why 120 bits?? -NM]
+       A list of introduction points. If the optional "secret-cookie" is
+       used, this list is encrypted with AES in CTR mode with a random
+       initialization vector of 128 bits that is written to
+       the beginning of the encrypted string, and the "secret-cookie" as
+       secret key of 128 bits length.
 
-       The encrypted-string is encoded in base64, and surrounded with
-       "-----BEGIN AES ENCRYPTED MESSAGE-----" and
-       "-----END AES ENCRYPTED MESSAGE-----".
+       The string containing the introduction point data (either encrypted
+       or not) is encoded in base64, and surrounded with
+       "-----BEGIN MESSAGE-----" and "-----END MESSAGE-----".
 
        The unencrypted string may begin with:
 
@@ -263,8 +271,8 @@
 
            [At start, exactly once]
 
-           The identifier of this introduction point.
-           [XXXX What's the identifier? -NM]
+           The identifier of this introduction point: the base-16 encoded
+           hash of this introduction point's identity key.
 
          "ip-address" ip-address NL
 
@@ -297,8 +305,12 @@
 
            [Any number]
            [XXXX this is valid at the start *and* at the end? -NM]
+           [These are two separate "authentication" fields. The one above
+            is global and independent from the introduction points, and
+            this one is specific for one introduction point. Should we use
+            different names for them? -KL]
+           [Probably. -NM]
 
-
         (This ends the fields in the encrypted portion of the descriptor.)
 
      "signature" NL signature-string



More information about the tor-commits mailing list