[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] Remaining 4 bits in prop224 addresses



Jesse V <kernelcorn@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev