On 2 Jan 2018, at 10:51, nullius nullius@nym.zone wrote:
On 2018-01-01 at 22:36:53 +0000, Taylor R Campbell campbell+tor-dev@mumble.net wrote:
Date: Sun, 31 Dec 2017 11:46:28 +0000 From: Alec Muffett alec.muffett@gmail.com
Or, indeed, you could leave out the hyphens and do the same; the Prop224 Onion address is 59 characters, leaving a budget of 63-59==4 characters or 20 bits; we could put these at the end, in the space marked "@@@@":
https://www4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad@@@@.onio...
Actually, the label part is 56 characters, not 59 characters. rend-spec-v3.txt, § 6 [ONIONADDRESS]. See also § 1.2 [NAMING] (“The result is a 56-character domain name”—nit, that should be “label”).
We would happily take a patch that makes the wording more precise throughout the proposal and Tor's other specifications.
…
N.b. that this still includes the two octets of truncated SHA3-256, wrapped inside a format with 30 bits of error-correcting BCH code. Decoding/re-encoding the name to drop the SHA3 bits would cut the payload from 280 to 264 octets, which could be represented in 53+6=59 Bech32 characters with the BCH ECC.
You could safely drop and recalculate the hash, but if the onion address encoding changes in a future version, you would have to patch all the bech code.
I also question whether the onion version needs a whole octet. In the specific application of Bech32 to Bitcoin, the “witness version” (version of encoded tx auth program) is restricted to 0–16, inclusive; and the Bech32 coding is done with one of what I will call a “quintet” char (5 bits) for the version, followed by the encoding of 8-bit octets of the witness program.[0] If the .onion version were resticted to 0–15 so as to fit in 4 bits, then only 260 bits = 52 quintets would be needed to express the version plus the 256-bit master identity key. How many .onion address versions are expected in, say, the next 20–30 years? Adding a 6-char BCH code, the total label length would be 58 quintet characters.
At these lengths, I think every character of pseudorandom data which can be reasonably shaved off is a significant win for wetware UX.
We won't be revising the spec at this point, because it's been implemented. However, you could suggest that the next version of onion services only uses 5 bits to encode the version.
You could safely encode the current version 3 in zero bits, but if the onion address encoding changes in a future version, you would have to patch all the bech code.
One way of doing this is to make the bech prefix "onion3".
...
T