[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Length of new onion addresses

Length is not nearly as important as bookmarkability. You mentioned
that you are going to be changing stuff every day. That worries me.


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.


Your other ideas: Breaking things into parts:

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/


I like this much, much more.


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/


I think this is the best. Use the current system for sites using the
old method (central servers mapping .onion addresses to introduction
points), and a onion.secretkey.hidden for stuff using the new,
non-central servers.


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.


Business cards? Hadn't thought of that. Yea, that would give a bonus to short.