[tor-dev] Remaining 4 bits in prop224 addresses

[Jesse V]

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.

-- 
Jesse

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 720 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20161206/3d648064/attachment.sig>