> On 24 Jan 2017, at 00:36, George Kadianakis <desnacked@xxxxxxxxxx> 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 ------------------------------------------------------------------------
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev