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