Jesse V <kernelc...@torproject.org> writes: > 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?) > > 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. >
Thanks for bringing up this topic Jesse. I'd be interested in both a version field and a checksum to be part of the encoding of the onion address. I also don't mind extending the encoding by a character or two if that will make it more useful (there is little difference between 54 and 56 characters). WRT version field, should it be a single value/bitmap or should it be able to denote support for multiple versions? WRT checksum, how much of the address can we protect using a checksum of 1 or 2 bytes? My error-correcting-codes fu is a bit rusty, and I'm not sure how many errors we can detect/correct. Anyone can do some digging here and prepare a table, so that we can take an informed decision? Perhaps the bitcoin community has already done this for us. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev