[tor-dev] Remaining 4 bits in prop224 addresses
George Kadianakis
desnacked at riseup.net
Fri Jan 6 13:42:23 UTC 2017
Jesse V <kernelcorn at torproject.org> writes:
> 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.
>
Hello people and happy new year :)
I think at this point the best way forward would be for someone to take
initiative and write a Tor proposal on how onion addresses should be
encoded/represented. This way we will have something concrete that we
can discuss and work with.
Anyone interested? If not, I will get to it in a few months.
peace
More information about the tor-dev
mailing list