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

[Ivan Markin]

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