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