[tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

chelsea komlo me at chelseakomlo.com
Sat Jan 28 17:19:24 UTC 2017


On 01/28/2017 10:16 AM, segfault wrote:
> I share your concerns here. I think we could work around this by pulling
> the version byte out of the base32 encoding, like this:
>   onion_address = base32(pubkey + checksum) + "-" + version
> This would result in onion addresses like this:
>   tbi5tdxbosiotphawjyu7f5pw5tlnvbvfjrj7meskbsnwr2bqbu2t4g-1.onion
> If the HS version changes to version 2, the onion address would only
> change in the version char:
>   tbi5tdxbosiotphawjyu7f5pw5tlnvbvfjrj7meskbsnwr2bqbu2t4g-2.onion
> This way onion service operators can keep their onion address prefix and
> users can verify that the new address uses the same public key as the
> address of the previous version.
> What do you think about this? 

I think this is could be an option if the HS version is needed in the
client request when fetching the descriptor from the HSDir. It is my
understanding that the HS version is already encoded in the descriptor,
so theoretically the version can be removed from the client request

The scheme you describe above still may have distribution problems, and
possibly still puts responsibility on the end user. For example, say the
following happens:

1. Tor releases HS version 5 (a new version)
2. The New York Times HS has not yet upgraded, and remains on version 4
for a period of time.

As a Tor client, how do I know whether to use


? Either my Tor client can try version 5 by default (the highest version
supported) and then fall back to version 4, or it can be the
responsibility of the end user to check whether the New York Times has
upgraded. Both of these scenarios are prone to error, and the second is
difficult to scale. If we can leave out the HS version from the client
request and publish HS versions only in the descriptor,  it seems like
these issues could be mitigated.

Let me know what you think, or if the above scenarios can be mitigated
in other ways.

More information about the tor-dev mailing list