Re: [tor-dev] Error-Correcting Onions with Bech32

[teor <teor2345@xxxxxxxxx>]

> On 2 Jan 2018, at 10:51, nullius <nullius@xxxxxxxx> wrote:
> 
> On 2018-01-01 at 22:36:53 +0000, Taylor R Campbell <campbell+tor-dev@xxxxxxxxxx> wrote:
>>> Date: Sun, 31 Dec 2017 11:46:28 +0000
>>> From: Alec Muffett <alec.muffett@xxxxxxxxx>
>>> 
>>> 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@@@@.onion/
> 
> 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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev