> On 7 Dec. 2016, at 09:47, Jesse V <kernelc...@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 ------------------------------------------------------------------------ _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
