proposal 114: changed descriptor format, key length discussion, typos

  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:

    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

        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

  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

  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]

    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.

    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.

       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 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 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.