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

[George Kadianakis <desnacked@xxxxxxxxxx>]

s7r <s7r@xxxxxxxxxx> writes:

> Hello George,
>
> George Kadianakis wrote:
>> Hello list,
>> 
>> we've had discussions over the past years about how to encode prop224 onion
>> addresses. Here is the latest thread: https://lists.torproject.org/pipermail/tor-dev/2016-December/011734.html
>> 
>> Bikeshedding is over; it's time to finally pick a scheme! My suggested scheme
>>
>> <snip>
>> 
>
> The version field is useful and allows room for much stuff that we might
> need to do. I think it would be better to place it at the end of the
> address. I don't think all addresses should start with the same prefix
> tbh - this will make them slightly less distinguishable (as much as
> possible users should be able to differentiate onion addresses, which
> are re-usable for long term, as opposite to Bitcoin where the
> recommended way is to use 1 address 1 time, different one every time and
> the users just need to see a string that looks and reads like a Bitcoin
> address and just make sure it's copied (scanned) from/to the right place).
>

OK thanks for the useful discussion. I identified at least three feedback points:

+ Screw base58 it's not gonna work. We stick to base32. Usability will
  be "restored" with a proper name system.

+ Move version byte to the end of the address to avoid constant
  prefix. Moving version byte to the middle as teor suggested would
  cause forward-compatibility issues.

+ My checksum calculations were wrong. Checksum is strong! 2 bytes are enough.

And given the above, here is the new microproposal:

  onion_address = base32(pubkey || checksum || version)
  checksum = SHA3(".onion checksum" || pubkey || version)

  where:
       pubkey is 32 bytes ed25519 pubkey
       version is one byte (default value for prop224: '\x03')
       checksum hash is truncated to two bytes

  Here are a few example addresses (with broken checksum):

       l5satjgud6gucryazcyvyvhuxhr74u6ygigiuyixe3a6ysis67ororad.onion
       btojiu7nu5y5iwut64eufevogqdw4wmqzugnoluw232r4t3ecsfv37ad.onion
       vckjr6bpchiahzhmtzslnl477hdfvwhzw7dmymz3s5lp64mwf6wfeqad.onion
  
  Checksum strength: The checksum has a false negative rate of 1/65536.

  Address handling: Clients handling onion addresses first parse the
  version field, then extract pubkey, then verify checksum.

Let me know how you feel about this one. If people like it I will
transcribe it to prop224.

Thanks again Ivan, Ian, Linda, teor, s7r, Chelsea :)
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev