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

[David Goulet]

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

-- 
roxgbXXp4m276fgnLQpnruSx0I3Gz71Mfnx0ButjTVU=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170124/c95d57f7/attachment.sig>