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

[s7r]

Hello,

David Goulet wrote:
> <snip>
>>
>> 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.
> 

I like the proposal in this form - Yes for all points.

I also dislike being possible to have multiple addresses (versions) for
the same public key, that would create implementation and usability
problems.

I wouldn't go for the hypens, but even if we decide at a later point
that this was a good idea we can handle it at an upper layer, like with
a browser tool or something, it's outside the scope of this
microproposal. We all know only a naming system will really fix this
issue from all points of view, so let's stick to that.

Thanks for this! Really great work.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170124/c08ea5cd/attachment.sig>