[tor-dev] Remaining 4 bits in prop224 addresses

[David Goulet]

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161206/bf69866d/attachment.sig>