Hi George,
George Kadianakis:
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. 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. A heavier alternative would be to have two bytes of version so that we can just prefix them all with 'tor'...
Yes, this is definitely good idea to introduce version octet. Though it seems pretty redundant to me to prefix onion addresses with 't'/'tor'. I think that the version octet should increment as you described above. I think that version should placed at the end of the address. This would make addresses more distinguishable addresses among each other.
[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. 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:
Is that necessary? Two bytes seem to be more than enough for typo-level error.
[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
I'm personally consider both base64 and base58 having poor UX and agree with Linda. Mostly it's because they are case-sensitive - this makes them too hard to type in. Also base58 has non-integer bit capacity that makes implementation way more complicated and error-prone (we've seen enough bugs even in b32 and b64 implementations).
---
I had an idea recently that having variable-length flexible addresses in fashion similar to TLVs in OTR protocol would be nice. In that case there are no more length constraints at all, so we may use keys of different types/sizes (pq?), embed authentication data, etc, etc.
Type: 1 byte Length: 1 byte (=up to 255 bytes= 2040 bits) Value: Length bytes
0x01 0x20 [0x01..0xff] 0x33 0x02 [0x11 0x99] ".onion" T T T T T T | | | | | +-- two-byte checksum | | | | +----------- length of the checksum | | | +---------------- checksum type | | +-------------------------- ed25519 pk | +---------------------------------- size of pk (32 bytes) +--------------------------------------- prop224 identity key type
So, its length now 1+1+32 + 1+1+2 = 38 byte = 61 base32 chars with one (1) unused bit. E.g.: obdczrndtadzdhb6iyemnxf7f4i6x7yojnunarlrvt2virtmrecmwgx5golqe.onion
Despite of using more bytes (type/length) it provides freedom for future adjustments (e.g. another checksum/key algo). Also these TLVs are commutative so changing order has no effect (maybe should, like in DER?). As a side effect plain-old-onion-addresses can be encoded here (even with a checksum).
I'm not sure whether it's reasonable as it seems to me.
-- Ivan Markin