[tor-dev] Remaining 4 bits in prop224 addresses

[teor]

> On 7 Dec. 2016, at 09:47, Jesse V <kernelcorn at torproject.org> wrote:
> 
> 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.

A more appropriate construction here is:
H(prefix + version + edDSA_address)
Where prefix is a static string identifying the purpose of the hash.

That way, hash re-use becomes difficult - tables must be re-built for every
different prefix.

T

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------