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

[teor]

> On 24 Jan 2017, at 00:36, George Kadianakis <desnacked at riseup.net> wrote:
...
> [D1.1] Default version value:
> 
>      The next question is what version value to assign to normal onion
>      services. In the above scheme where:
> 
>         onion_address = base32(version + pubkey + checksum)
> 
>      the value of 'version' basically determines the first two characters of
>      the onion address. In Bitcoin, they've made it such that the default
>      version value basically prefixes addresses with "1"; so all normal
>      Bitcoin addresses start with 1 as in 14tDWDT9zqDufWZmiLqoaT9qJyHi7RRZPE
> 
>      What should we do in Tor? My suggestion is to use '\x98' as the default
>      version value which prefixes all addresses with 't' (as in Tor).  Check
>      the examples I cited above.

As Linda said, using a common prefix makes it much harder for people to
distinguish addresses.

(People check the start, then the end, and tend to ignore the middle.)

>      An alternative is to turn the scheme to:
>        onion_address = base32(pubkey + checksum + version)
>      where the version byte is at the end with no effect at usability.

Using a common suffix makes it somewhat harder for people to distinguish
addresses.

I suggest:

onion_address = base32(pubkey + version + checksum)

That way, the identical part of the address is in an area people
typically ignore when doing comparisons.

>      A heavier alternative would be to have two bytes of version so that we
>      can just prefix them all with 'tor'…

This is even worse for distinguishability.

> [D2] Checksum strength:
> 
>      In the suggested scheme we use a hash-based checksum of two bytes (16 bits).
>      This means that in case of an address typo, we have 1/65536 probability
>      to not detect the error (false negative). It also means that after 256
>      typos we will have 50% probability to miss an error (happy birthday!).
> 
>      I feel like the above numbers are pretty good given the small checksum size.

Two bytes or 1/65536 is quite fine. 1/256 would even be acceptable.

>      The alternative would be to make the checksum four bytes (like in
>      Bitcoin).  This would _greatly_ increase the strength of our checksum but
>      it would also increase our address length by 4 base32 characters (and
>      also force us to remove leading padding from base32 output). This is how
>      these 60-character addresses look like:
> 
>         tc2dty3zowj6oyhbyb5n3a2h3luztlx22hy2cwdvn37omsv7quy7rxiysn3a.onion
>         tbdczrndtadzdhb6iyemnxf7f4i6x7yojnunarlrvt2virtmrecmwgx5golq.onion
>         tc6pcgyorusw3jj5tosxakmcwfmcend2q4g2qnbjtkhuuh4dcgvs4rl4rdaa.onion
> 
>      You probably don't notice the size difference compared to the
>      56-character addresses, which perhaps is an argument for adopting a four
>      byte checksum. Let me know what you think about this.

Four bytes seems unnecessary, we only gain a very small advantage from
adding those extra bytes to every address.

> [D3] Do we like base32???
> 
>      In this proposal I suggest we keep the base32 encoding since we've been
>      using it for a while; but this is the perfect time to switch if we feel
>      the need to.
> 
>      For example, Bitcoin is using base58 which is much more compact than
>      base32, and also has much better UX properties than base64:
>         https://en.bitcoin.it/wiki/Base58Check_encoding#Background
> 
>      If we wanted to get a more compact encoding, we could adopt base58 or
>      make our own adaptation of it. In this proposal I'm using base32 for
>      everything, but I could be persuaded that now is the time to use a better
>      encoding.

As far as I understand it, .onion domain registrations require addresses
that conform to DNS rules: in particular, they must be case-insensitive,
and within DNS component length and total length restrictions.

So base58 and base64 are out.

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170124/ac3f2a60/attachment-0001.sig>