On 2017-01-24 08:00, David Goulet wrote:
On 24 Jan (14:27:43), George Kadianakis wrote:
s7r s7r@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.onionChecksum 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@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.