[or-cvs] r10413: proposal 114: changed descriptor format, key length discussi (tor/trunk/doc/spec/proposals)

[kloesing@xxxxxxxx]

Author: kloesing
Date: 2007-05-30 05:01:10 -0400 (Wed, 30 May 2007)
New Revision: 10413

Modified:
   tor/trunk/doc/spec/proposals/114-distributed-storage.txt
Log:
proposal 114: changed descriptor format, key length discussion, typos

Modified: tor/trunk/doc/spec/proposals/114-distributed-storage.txt
===================================================================
--- tor/trunk/doc/spec/proposals/114-distributed-storage.txt	2007-05-30 08:56:43 UTC (rev 10412)
+++ tor/trunk/doc/spec/proposals/114-distributed-storage.txt	2007-05-30 09:01:10 UTC (rev 10413)
@@ -10,6 +10,7 @@
 
   13-May-2007  Initial proposal
   14-May-2007  Added changes suggested by Lasse Overlier
+  30-May-2007  Changed descriptor format, key length discussion, typos
 
 Overview:
 
@@ -216,15 +217,16 @@
     date, and "cookie" is a shared secret between the hidden service provider
     and its clients. (The "time-period" should be constructed in a way that
     periods do not change at the same moment for all descriptors by including
-    the "permanent-id" in the construction.) Amonst other things, the
+    the "permanent-id" in the construction.) Amongst other things, the
     descriptor contains the public key of the hidden service provider, the
     value of h(time-period + cookie), and the signature of the descriptor
     content with the private key of the hidden service provider.
 
     The introduction points that are included in the descriptor are encrypted
     using a key that is derived from the same shared key that is used to
-    generate the descriptor ID. [usage of a derived key as encryption key
-    instead of the shared key itself suggested by LO]
+    generate the descriptor ID. [correction to use another key than
+    h(time-period + cookie) as encryption key for introduction points made by
+    LO]
 
     A new text-based format is proposed for descriptors instead of an
     extension of the existing binary format for reasons of future
@@ -238,8 +240,8 @@
         h(time-period + cookie)
         timestamp
         {
-          list of (introduction point IP, port, public service key)
-        } encrypted with h(time-period + cookie + 'introduction')
+          list of intro points (ID, IP, onion port, onion key, service key)
+        } encrypted with cookie
       } signed with permanent-private-key
 
     A hidden service directory can verify that a descriptor was created by the
@@ -331,7 +333,7 @@
 
   The proposed changes affect multiple sections in several specification
   documents that are only mentioned in the following. The detailed
-  specification will follow as soon as the design decision above are final.
+  specification will follow as soon as the design decisions above are final.
 
   dir-spec-v2.txt
 
@@ -392,24 +394,25 @@
 
   There are three key lengths that might need some discussion:
 
-    1) desciptor-id, formerly known as onion address: It is generated by OPs
+    1) descriptor-id, formerly known as onion address: It is generated by OPs
        internally and used for storing and looking up descriptors. There is no
        need to remember a descriptor-id for a human. In order to reduce
-       the success rate of collisions it could be extended to 256 bits instead
-       of 80 bits. This requires a secure hash function with an output of 256
-       instead of 160 bits, e.g. SHA-256. [extending the descriptor-id length
-       from 80 to 256 bits suggested by LO]
+       the success rate of collisions it could be extended to the full output
+       of SHA-1 of 160 bits instead of 80 bits. [extending the descriptor-id
+       length suggested by LO]
 
-    2) permanent-id: This is the first half of the onion address that a client
-       passes to his OP. The onion address should be easy to memorize.
-       Therefore, the overall length of an onion address should not be
-       extended over the existing 80 bits, so that 40 bits is the maximum
-       length of the permanent-id. However, the question remains open, if an
-       onion address of 40+40=80 bits can generate a descriptor-id with enough
-       entropy to justify 256 instead of 80 bits. Otherwise, the onion address
-       would need to be extended to 128, 160, 224, or 256 bits, making it
-       harder to memorize for human-beings.
+    2) permanent-id: This is the first part of the onion address that a client
+       passes to his OP. The overall onion address should be easy to memorize.
+       Therefore, its overall length should only be extended from the existing
+       80 bits to as few bits as necessary. The length of the permanent-id has
+       an influence on the probability that an adversary creates an own key
+       pair that leads to the same descriptor-id in a given time-period as an
+       honest service's key. 32 bits should provide sufficient protection to
+       avoid collisions, given the fact that key generation is expensive and
+       the attack needed to be performed for every time-period.
 
-    3) cookie: This is the second half of the onion address that is passed to
-       an OP. It should have the same size as permanent-id.
+    3) cookie: This is the second part of the onion address that is passed to
+       an OP. In order to provide confidentiality of introduction points, this
+       secret key should have 128 bits. In total, this leads to an onion
+       address of 160 bits instead of the current 80 bits.