[tor-dev] Remaining 4 bits in prop224 addresses

[Jesse V]

On 12/06/2016 11:27 AM, David Goulet wrote:
> We had little discussion but some of us agree for sure on having bits for the
> version number. That will tell a tor client to fetch the right descriptor
> instead of trying all version that have the same type of public key (.onion
> address). We currently have I believe 4 bit left which is only 16 values so we
> could extend to one more byte here so have more room.

I'm curious if we ever ran into this issue with the current HS protocol.
What type of changes would warrant a new address that that could not be
solved with a patch to the tor binary? We also need to consider the
difficulty of distributing a one-character-different address against the
difficulty of transitioning the network to the new descriptors. People
get very entrenched to their onion address, bookmark them, and some even
issue SSL certs for them.

Let's say we added another character, so that we have 9 bits free. Would
would be the consequence of using all 9 bits for a checksum? We could
solve the version/descriptor issue using a naming system and simply
point the name to a newer onion address. It's something to consider.

> Second thing that is possible, like you stated above, is a checksum.
> Unfortunately, I haven't thought much about this nor know the "state of the
> art of small-checksum" but definitely something to dig through! Jessie, if you
> feel like it, I welcome any analysis you can do on checksum here and some
> proposal about it. (Only if you want to :).

I'm not fluent in the arts of small checksums, but it seems to me that
we do have some benefit of using the first N bits of SHA2(version +
edDSA_address) as the checksum. I may not have time to write a full
proposal, but even with a small number of bits we do have a decent
chance of catching typos, which is the whole point. Obviously, this
chance will get better as you add more bytes, but prop224 addresses are
already fairly long and we should weigh the usability impact against the
probability of typos.

-- 
Jesse

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