On 06 Dec (07:05:47), Jesse V wrote:
Hello all,
I've been closely following the other Proposal 224 threads regarding the next-generation of onion services. I'm glad to see that we have a timeline and plan for migrating the network. One unresolved point is what to do with the remaining 4 bits in the longer addresses. Section 1.2 in the 224 document states "Note that since master keys are 32 bytes long, and 52 bytes of base 32 encoding can hold 260 bits of information, we have four unused bits in each of these names." It seems a waste for these to be zeroed out. The four bits could also be used to hold client-side flags, but I'm not aware of any applicable client settings that could be used here. I suggest that we use them as a checksum. (wasn't this proposed in Arlington?)
Fun fact, that discussion was part of the "other tor-dev@ thread" I was planning to do after torrc discussion ;).
Since speed isn't a priority, aside from Adler-32 or some CRC function, we could also hash the 32-byte key and use the first four bits of the hash. I think a checksum is best because it helps ensure data integrity when the address is shared online, copy/pasted, or physically written down. Bitcoin addresses contain a checksum as well for exactly this reason. They use a combination of SHA-256 and RIPEMD-160 to compute the checksum component. Source:
https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_address... 2) https://bitcoin.stackexchange.com/questions/32353/
What do we think about a checksum, or do we have other plans here? I ask because once we nail down the address format, I can add support for 224 into my Onion Name System.
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.
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 :).
Thanks! David
-- Jesse
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev