On 24 Jan 2017, at 00:36, George Kadianakis desnacked@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 ------------------------------------------------------------------------