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

[Linda Naeun Lee]

On 2017-01-24 08:00, David Goulet wrote:
> On 24 Jan (14:27:43), George Kadianakis wrote:
>> s7r <s7r at sky-ip.org> 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.
> 
> I like this quite a bit! Simple, easy, and trivial to understand. 56
> characters address, after that it will be the time to improve UX/UI 
> with all
> sorts of possible tricks to make them easier to remember or copy paste 
> or
> visualize or what not.
> 
> Unless some feedback NACK this, I say push that in the proposal soon. 
> I'll
> personally start implementing that scheme this week.
> 
> Thanks!
> David
> 
>> 
>> Thanks again Ivan, Ian, Linda, teor, s7r, Chelsea :)
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev at lists.torproject.org
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

+1; I like this proposal.

The hyphens help, but I don't think that is the only solution (though I 
have no alternatives at the moment, except having short and 
pronounceable names, which doesn't have the technical properties we 
want) and we should be careful as it can introduce complexity/forward 
compatibility issues.

-- 
Current Key: https://pgp.mit.edu/pks/lookup?search=lindanaeunlee
GPG Fingerprint: FA0A C9BE 2881 B347 9F4F C0D7 BE70 F826 5ED2 8FA2