Length of new onion addresses

[Karsten Loesing <karsten.loesing@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(posting to or-talk and or-dev, because it concerns both, usability and
development)

Hi,

at the moment I am designing the new ASCII-based format for hidden
service descriptors, including new security features like encryption of
introduction points and the ability to be distributed among onion
routers unpredictably for non-clients. This incorporates a secret cookie
that needs to be passed between the hidden service provider and his
clients in addition to the service id which is the current onion
address. You can read about all the details in proposal #114 in the svn
repository.

As the new descriptor might replace the current descriptor some day and
the format of onion addresses would affect all hidden service users, I
would like to discuss this decision of the onion address format in
public, rather than make a decision on my own and being confronted with
incomprehension when it might be introduced.

The current onion addresses consist of 80 bits and (as you all know)
look like this (address of the hidden wiki):

http://6sxoyfb3h2nvok2d.onion/

The new onion addresses would consist of two parts: (1) the service id
and (2) the secret cookie.

(1) In contrast to the current format, the service id is not used to
identify the service (bad name then, I know), but to generate an
unpredictable descriptor id where to find the service descriptor. If an
adversary can create an own key pair with a fingerprint equal to the
service id, she can prevent the actual hidden service from announcing
his service. Though, the effect of this is limited, because descriptor
ids are automatically changed every day. My idea was to use 32 bits for
the service id.

(2) The secret cookie is the key for encrypting and decrypting the
introduction points and to calculate the current descriptor id. Whoever
finds out the secret cookie could observe hidden service activity and
attack introduction points which both would otherwise not be possible.
My plan was to use a 128 bit key as secret cookie.

In total, new onion addresses would be 160 bits long. The question is
now, if an onion address of that size is still manageable for human
beings? (Is the current size manageable after all?) For illustration
purposes, the new addresses would look like this:

http://6sxoyfb3h2nvok2d6sxoyfb3h2nvok2d.onion/

Or are my assumptions concerning the length of the service id still too
incautious, and would 200 bits (72 bits for service id and 128 bits for
the secret cookie), resulting in the following onion address, be better?

http://6sxoyfb3h2nvok2d6sxoyfb3h2nvok2d6sxoyfb3.onion/

For downward compatibility reasons, those 200 bits could also be
distributed by using 80 bits for the service id and 120 bits for the
secret key. Then, people could start using the new descriptor by simply
adding a dot and a secret cookie to their current (unchanged) onion
address. This would look like this:

http://6sxoyfb3h2nvok2d.6sxoyfb3h2nvok2d6sxoyfb3.onion/

To the (probably upcoming) question, why one needs a secret cookie at
all, or if it could also be used optionally in the long run: The plan is
to distribute the storage of descriptors, primarily for scalability
reasons. But this raises new security issues, because anyone running a
stable onion router could become responsible for storing a descriptor,
so that we simply need new security mechanisms. Otherwise, security
would be worse by the distribution, but with the secret cookie, security
even gets better than before.

But perhaps we should rather aim for usability than for security and use
only 120 bit long onion addresses, e.g. by using 32 bits for the service
id and 88 bits for the cookie, resulting in the following onion address?

http://6sxoyfb3h2nvok2d6sxoyfb3.onion/

Maybe we shouldn't even extend the onion addresses at all, but allocate
the 80 bits in another way, e.g. 24 bits for the service id and 56 bits
for the secret cookie? Then we should use another virtual top level
domain to distinguish current and new descriptors, resulting in
something like the following:

http://6sxoyfb3h2nvok2d.hidden/

What do you guys prefer? How do you exchange onion addresses? Publishing
them on non-hidden web pages, pasting them to IRC chats, writing them on
business cards, memorizing and telling them, ...? I think it's important
to find a balance between security and usability here.

The question is: Does size matter? :)

Any comments are welcome! Thanks!

- --Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGX/ks0M+WPffBEmURAg42AJ9l6aDu++f1Ozaesouxxm4d82rdwgCgsC8l
l0858q0gkfWYlcOG3odyT+s=
=BGOH
-----END PGP SIGNATURE-----