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: > 1) > https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses > 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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev