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

[teor]

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

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

[nullius]

On 2018-01-01 at 22:36:53 +, Taylor R Campbell 
 wrote:

Date: Sun, 31 Dec 2017 11:46:28 +
From: Alec Muffett 

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”).  
Using the first example example address therefrom:


$ bech32 -e pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion
onion10x7vvfgcfvz3jjt4c29kddntq35l0aj4d7c6cvvf57d5phdr9u0jz3crm5jhsx

Of course, 56 + 6 = ...

$ echo -n \
0x7vvfgcfvz3jjt4c29kddntq35l0aj4d7c6cvvf57d5phdr9u0jz3crm5jhsx \
| wc -c
62

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.


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.


0. Note, Bech32 encoding rules do not require that the encoded bit 
length be a multiple of 5.  The standard prescribes the simple rule that 
strings of octets be zero-padded to a multiple of 5 bits when encoding, 
and decoded to octets with up to 4 trailing 0 bits discarded.

https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki


Existing checksum in v3 addresses aside, what would prevent using a
second DNS label for a longer checksum if you wanted a bigger budget?

The labels are limited to 63 octets, but the whole name can be up to
255 (including label length bytes).


I expect that the user burden of a greater length of pseudorandom 
gibberish would outweigh any possible UX benefit of adding more checksum 
data.  A 6-quintet BCH code already provides error correction, 
guarantees detection of errors affecting not more than 4 characters, and 
has a <10^-9 probability of failing to detect a greater number of 
errors.  Is better than that really needed?


Upon the same cryptographic self-validation principle which .onion 
applies in the first place, I have also considered such possibilities as 
encoding a TLS public key fingerprint in subdomain labels.  The 
fingerprint could be automatically verified by the connecting TLS client 
against the same data it itself provides via SNI.  This could alleviate 
the current need to get CAB Forum to approve some form of DV for .onion 
certificates.  However, the results must be considered absolutely 
impracticable for humans transcription.  The usage model would rely 
exclusively on bookmarks, copypaste, etc.


--
null...@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No!  Because I do nothing wrong, I have nothing to show.” — nullius


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Taylor R Campbell]

> Date: Sun, 31 Dec 2017 11:46:28 +
> From: Alec Muffett 
> 
> 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/

Existing checksum in v3 addresses aside, what would prevent using a
second DNS label for a longer checksum if you wanted a bigger budget?

The labels are limited to 63 octets, but the whole name can be up to
255 (including label length bytes).
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[teor]

Hi,

> b) if Onion addresses have 2+ forms, one like the current 
> (www.4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion) and the 
> other being apparently more human-usable because it contains a CRC, the one 
> which allows access to websites will win.

What if they both allow access to websites?

I had always thought that prop#279 addresses would be
translated into their canonical forms before the browser
acts on them. But the current proof-of-concept
implementation would include them in the Host header,
because the translation is done at the Tor layer
(not the browser layer).

This also makes a mess of security certificates.
(Or it means that both names would need to be in the certificate.)

And there's the issue of having two names for the same site.

> My expectation to date has been that the problem with 
> "4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad" is that that there 
> is no place for the eyeball to rest when typing it in; as such I've presumed 
> that a canonical form, defined by Tor, would be something like:
> 
> https://www.4acth47i-6kxnvkew-tm6q7ib2-s3ufpo5-sqbsnzjp-bi7utij-cltosqem-ad.onion/
> 
>  ...being N groups of M characters (where N and M can be argued, feel free...)

That's not what's specified right now, and it not what will be
released in 0.3.2 in a few weeks.

But we could implement a grouping and checksum mechanism
like this using a prop#279 plugin, much like the bech transform.

Depending on where we do the name translation, this change
would cause the same Host header and certificate issues.

>> The advantage of a system like this is that it's not perfect, but a typo 
>> mostly has to happen twice and be quite fortunate to go undetected.
>> Of course it's not perfect, but nothing will be, and clever selection of 
>> checksum and encoding will result in something which is still DNS- and 
>> Browser-compliant.
> 
> One other advantage: a DNS-format-compliant checksum like this could be 
> trivially baked into an SSL certificate without requiring CA/Browser Forum to 
> invent a wholly new kind of certificate just-for-Tor

This is true. We should make any schemes DNS-compliant,
which is how the examples in prop#279 work.

> This would result in Prop224 Onion Addresses which would not only be 
> typo-resistant, but could also continue to be issued with EV certificates 
> where site-attestation is beneficial.
> 
> Further: adding segment-checksum bits at the end would be (I think?) 
> backwards compatible with existing Prop224 addresses.

They would be compatible, as would most prop#279 addresses,
apart from the issues mentioned above.

Are you aware that there's already a checksum in v3 onion
service addresses?

"The onion address of a hidden service includes its identity public key,
a version field and a basic checksum."

https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n2012

T___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[Alec Muffett]

On 31 December 2017 at 02:46, nullius  wrote:

> For the foregoing reasons, I will propose that subdomain data, if any, be
> kept separate from the Bech32 coding.  It may be either kept in a separate
> string, or somehow affixed with a special delimiter either before or after
> the Bech32 representation of the onion.  Off-the-cuff, which of these looks
> best to you?
>
> www:onion19qzypww2zw3ykkkglr4tu9
>
> onion19qzypww2zw3ykkkglr4tu9:www
>
> another-level.www:onion19qzypww2zw3ykkkglr4tu9
>
> (My choice of a delimiter here may be wrong, if we want for the browser’s
> address bar to translate it.  I should think more about this.)
>


I need to think about this more, and after coffee, but my first concerns
would be:

1) that having multiple representations of a site's onion address is likely
to break many/most sites, because of Host/Origin headers being complicated
enough already.

2) anything involving colons in any position ("https://
onion19qzypww2zw3ykkkglr4tu9:www/") is likely to break both
client-side-web-browsers and server-side-CMS-software unless they are
specially re-engineered for Tor, which is likely to inhibit use *of* Tor;
colons are a port-number separator in URLs, unless they come as part of an
IPv6 address in [square brackets].


My general sense is that:

a) if Onion addresses suddenly stop looking very-similar-to DNS addresses,
Tor risks returning to a world where special expertise is necessary to
build software for it, thereby harming growth/adoption

b) if Onion addresses have 2+ forms, one like the current (www.
4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion) and the
other being apparently more human-usable because it contains a CRC, the one
which allows access to websites will win.


My expectation to date has been that the problem with "
4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad" is that that
there is no place for the eyeball to rest when typing it in; as such I've
presumed that a canonical form, defined by Tor, would be something like:

https://www.
4acth47i-6kxnvkew-tm6q7ib2-s3ufpo5-sqbsnzjp-bi7utij-cltosqem-ad.onion/

 ...being N groups of M characters (where N and M can be argued, feel
free...) and where any unused characters within the 63-character
DNS-compliant budget can be used to implement a credit-card-like running
checksum or CRC, for quick client-side checks; eg: the URL bar can identify
that you are typing in an Onion address and leave it red-or-grey until you
type something which satisfies the checksum, before flinging it at
tor-daemon for attempted resolution.

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/

and use those 20 bits to implement 5x 4-bit checksums over 12-character
chunks:

   https://{www
4acth47i6}{kxnvkewtm6q7}{ib2s3ufpo5sq}{bsnzjpbi7uti}{jcltosqemad@}@@@.onion/

...so that any UX component which wants to help the user can highlight (in
red? or bold?) where the problem is, picking out a chunk of 12 characters
which contain the typo:

   https://www4acth47i6kxnvkewtm6q7*ib2s3ujpo5sq*
bsnzjpbi7utijcltosqemadwxyz.onion/
  -

Spot the errant 'j'.

The advantage of a system like this is that it's not perfect, but a typo
mostly has to happen twice and be quite fortunate to go undetected.

Of course it's not perfect, but nothing will be, and clever selection of
checksum and encoding will result in something which is still DNS- and
Browser-compliant.

-a



-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[teor]

Hi,

Please read the naming layer API proposal before writing your proposal:

https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-api.txt

In particular, if you added a unique top-level domain (.bech?), you
would only have to specify how a the bech translation plugin works.
(It would be a much shorter proposal.)

> On 31 Dec 2017, at 13:46, nullius  wrote:
> 
> For the foregoing reasons, I will propose that subdomain data, if any, be 
> kept separate from the Bech32 coding.  It may be either kept in a separate 
> string, or somehow affixed with a special delimiter either before or after 
> the Bech32 representation of the onion.  Off-the-cuff, which of these looks 
> best to you?
> 
>www:onion19qzypww2zw3ykkkglr4tu9
> 
>onion19qzypww2zw3ykkkglr4tu9:www
> 
>another-level.www:onion19qzypww2zw3ykkkglr4tu9
> 
> (My choice of a delimiter here may be wrong, if we want for the browser’s 
> address bar to translate it.  I should think more about this.)

Why not:

www.onion19qzypww2zw3ykkkglr4tu9

Transforming the final 2 components and leaving the rest intact seems
like the most usable form. Particularly if you're going  to add a .bech at
the end of the address for prop#279.

T___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

[nullius]

On 2017-12-31 at 00:57:49 +, Alec Muffett  
wrote:

Thanks! That's very interesting!  TIL :-)


Why, if it isn’t instant feedback from the RFC 7686 co-author!  In 
response to what you said, in brief:  I will propose that any subdomain 
data (which is presumably human-readable) be transmitted in a separate 
or affixed string, leaving Bech32 to deal with the pseudorandom blobs.  
Technical details follow.


What would you propose to do with subdomains, like 
www.facebookcorewwwi.onion? Or is that outside the scope of your 
proposal?


Good question.  That had briefly occurred to me; but I couldn’t figure 
out any feasible means to stuff subdomains into the Bech32 string, for 
the following reasons:


(0) RFC 1034 DNS names may be up to 255 octets in length.  But Bech32 
strings are more length-limited.  After subtracting an HRP of “onion” (5 
chars), the required separator of “1”, and the 6 characters of ECC 
checksum in the data part, the 90-character total length limit can only 
spare up to 78 characters for the onion address data.  For both v2 and 
v3 onions, that’s more than sufficient.  But even if the length limit 
could be raised, an excessively long string would destroy the 
human-friendliness which is the raison d’être for Bech32.


(I *infer* that this last may be one reason for the length limit.  
Although of course I can’t say for certain, I’ve read Greg Maxwell 
discussing some of the user testing involved in the standard’s 
development; and 90 chars seems to me the extreme of what a mortal 
flesh-and-blood creature could handle with such a string.)


(1) Bech32 is a base-32 encoding, only with a different alphabet than 
RFC 4648.  Thus, it would be necessary to design another layer of 
encoding to most efficiently represent subdomain labels and the 
dot-separator with an alphabet of 38 characters [-0-9a-z.].  Worse, 
depending on which standards an implementation follows or ignores, that 
is not really a strict limitation on names seen in the wild.  How should 
the Bech32 transformation deal with names containing an underscore “_”?  
Or other characters?  I think it would only be safe to go with full 
octets.  This would severely exacerbate the problem of (0) above.


(Aside:  The special alphabet is bound to raise some eyebrows; so I will 
here quote its rationale from BIP 173:  “The character set is chosen to 
minimize ambiguity according to [this](https://hissa.nist.gov/~black/GTLD/) 
visual similarity data, and the ordering is chosen to minimize the 
number of pairs of similar characters (according to the same data) that 
differ in more than 1 bit.  As the checksum is chosen to maximize 
detection capabilities for low numbers of bit errors, this choice 
improves its performance under some error models.”  From what I 
understand, a large amount of CPU time was spent crunching over the data 
in search of the most error-resistant alphabet.)


(2) Most subdomains are human-memorable—in your example, “www”.  Coding 
them with Bech32 would decrease human-friendliness, which is the precise 
opposite of my objective in making this suggestion.  Bech32 is great for 
helping humans deal with pseudorandom blobs; for those, it improves upon 
RFC4648 Base32, Base64, hexadecimal, or in Bitcoin’s case, the old 
base58-based address encoding.  But it is absolutely inappropriate as a 
coding format for text which humans can easily read, type, and remember.


It is also important to consider relative impact in common usage.  I 
observe that most .onions do not use subdomains.  I do think that it’s 
important to support this use case; but if tradeoffs must be made, then 
I would optimize more for making that pseudorandom blob less brittle in 
human hands.


For the foregoing reasons, I will propose that subdomain data, if any, 
be kept separate from the Bech32 coding.  It may be either kept in a 
separate string, or somehow affixed with a special delimiter either 
before or after the Bech32 representation of the onion.  Off-the-cuff, 
which of these looks best to you?


www:onion19qzypww2zw3ykkkglr4tu9

onion19qzypww2zw3ykkkglr4tu9:www

another-level.www:onion19qzypww2zw3ykkkglr4tu9

(My choice of a delimiter here may be wrong, if we want for the 
browser’s address bar to translate it.  I should think more about this.)


Finally, I think I should mention:  Yes, “onion19qzypww2zw3ykkkglr4tu9” 
is not as pretty as “facebookcorewwwi.onion”.  But few .onion sites have 
the compute power available to Facebook!  Moreover, my proposal should 
apply to v3 onions—where nobody on Earth will be able to fully 
bruteforce out a human-memorable string.


I would advise users to stick to the DNS-style coding for 
facebookcorewwwi.onion, and take advantage of Bech32 as an alternative 
representation for http://yz7lpwfhhzcdyc5y.onion/ , 
http://5nca3wxl33tzlzj5.onion/ , and other such strings.  Those are pure 
pain for users now, and it will only get use when v3 onions get 

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

[Alec Muffett]

Thanks! That's very interesting!  TIL :-)

What would you propose to do with subdomains, like
www.facebookcorewwwi.onion? Or is that outside the scope of your proposal?

- alec

On 31 Dec 2017 00:53, "nullius"  wrote:

> # Synopsis
>
> The Bech32 standard for error-correcting base32 strings was developed
> explicitly for relative ease and reliability in human communication of
> pseudorandom bitstrings.  I invite discussion of specifying Bech32 as an
> alternative means for representing RFC 7686 .onion domain names.  Should
> the response hereto be positive, then I will offer a formal proposal.
>
> I have written and released a tool which automatically recognizes and
> encodes/decodes .onion addresses in Bech32.  To complement whatever I here
> say, please get a hands-on feel for Bech32 .onions:
>
> https://github.com/nym-zone/bech32
>
> Manpage (yes, a real manpage!):
> https://raw.githubusercontent.com/nym-zone/bech32/master/bech32.1.txt
>
> # Background: About Bech32
>
> Bech32 is specified by the Bitcoin BIP 173 standard,[1] co-authored by
> Pieter Wuille and Greg Maxwell.  According to Mr. Maxwell, “Bech32 is
> designed for human use and basically nothing else”; the underlying research
> and development process involved extensive testing with human users,
> analysis of NIST visual confusability data, and the integration of a BCH
> code with strong error correction and detection properties.
>
> [1] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
>
> I refer to BIP 173 for further explanation of Bech32’s design properties,
> its rationales, and the limits of its error handling.
>
> A specific application of Bech32 is Bitcoin’s new address format for the
> future, which I call “Bravo Charlie Addresses” after the letters “bc”
> specified for Bitcoin addresses in the standard’s “human-readable part”
> (HRP).  However, the standard was written to permit general use in other
> applications.
>
> Having in hand a standard explicitly designed to ease the pain which
> wetware suffers when it comes into contact with pseudorandom gibberish, the
> cypherpunk in me is overjoyed at the potentials.  One is a concept which I
> call “PGP Descriptors”, which I am currently working to specify with a few
> extra features and nuances.  And of course, I think of .onions!
>
> # Bech32 for .onion
>
> I hereby nominate “onion” as the logical HRP for RFC 7686 .onion
> special-use domain names.
>
> Here is Bech32 .onion by example, using my bech32 tool with its built-in
> .onion support to encode and decode the name for the Tor Project’s .onion
> equivalent of its “www” site:
>
> ```
> $ bech32 -e expyuzz4wqqyqhjn.onion
> onion1yh0c5eeuksscs8fdyd8406
> $ bech32 -d onion1yh0c5eeuksscs8fdyd8406
> expyuzz4wqqyqhjn.onion
> ```
>
> The string is longer, because it contains 6 base32 characters’ worth of
> error-correcting code.  N.b. also, the foregoing should work just fine for
> v3 onions (formerly prop-224).
>
> Imagine the impact on users who have a practical need to transmit a .onion
> address by verbal communication, or via a handwritten note.  Now they can
> get some help with errors, instead of wondering why they can’t connect to a
> nonexistent .onion site.
>
> The standard enjoins applications against autocorrecting Bitcoin
> addresses, so as to prevent even the slightest possibility of causing funds
> loss by being too “helpful”.  But in applications where it would be safe to
> do so, Bech32 can indeed correct small errors (as well as reliably
> detecting much worse errors).  I suggest that such automatic correction
> would be suitable for .onion addresses.
>
> Bech32 co-author Dr. Wuille (sipa) has published Javascript reference
> code, plus a Javascript error-correction demo, under an MIT license.
> Perhaps this may be easily adapted into Torbutton, for automagic decoding
> of Bech32 “onion1” to .onion domains in the Tor Browser address bar.  The
> code is in the same repository whence I copied the Bech32 reference C code
> I use internally in my tool:
>
> https://github.com/sipa/bech32
>
> # Conclusion—or, to be continued...
>
> An alternative representational format with error-correcting codes will
> make .onion addresses more human-friendly.  I look forward to the day when
> “onion1” addresses can be passed by handwritten notes, vocalized with a
> radio alphabet, stuffed into QR codes, scrawled on parchments placed in
> bottles tossed to sea, rocketed into space, and then conveniently
> transformed with appropriate corrections into the DNS-style .onion format
> specified by RFC 7686.
>
> Here’s to the alternative Onion format of the future!
>
> --
> null...@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
> Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
> 3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
> “‘If you’re not doing anything wrong, you have nothing to hide.’
> No!  Because I do nothing wrong, I have nothing to show.” — 

[tor-dev] Error-Correcting Onions with Bech32

[nullius]

# Synopsis

The Bech32 standard for error-correcting base32 strings was developed 
explicitly for relative ease and reliability in human communication of 
pseudorandom bitstrings.  I invite discussion of specifying Bech32 as an 
alternative means for representing RFC 7686 .onion domain names.  Should 
the response hereto be positive, then I will offer a formal proposal.


I have written and released a tool which automatically recognizes and 
encodes/decodes .onion addresses in Bech32.  To complement whatever I 
here say, please get a hands-on feel for Bech32 .onions:


https://github.com/nym-zone/bech32

Manpage (yes, a real manpage!):
https://raw.githubusercontent.com/nym-zone/bech32/master/bech32.1.txt

# Background: About Bech32

Bech32 is specified by the Bitcoin BIP 173 standard,[1] co-authored by 
Pieter Wuille and Greg Maxwell.  According to Mr. Maxwell, “Bech32 is 
designed for human use and basically nothing else”; the underlying 
research and development process involved extensive testing with human 
users, analysis of NIST visual confusability data, and the integration 
of a BCH code with strong error correction and detection properties.


[1] https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki

I refer to BIP 173 for further explanation of Bech32’s design 
properties, its rationales, and the limits of its error handling.


A specific application of Bech32 is Bitcoin’s new address format for the 
future, which I call “Bravo Charlie Addresses” after the letters “bc” 
specified for Bitcoin addresses in the standard’s “human-readable part” 
(HRP).  However, the standard was written to permit general use in other 
applications.


Having in hand a standard explicitly designed to ease the pain which 
wetware suffers when it comes into contact with pseudorandom gibberish, 
the cypherpunk in me is overjoyed at the potentials.  One is a concept 
which I call “PGP Descriptors”, which I am currently working to specify 
with a few extra features and nuances.  And of course, I think of 
.onions!


# Bech32 for .onion

I hereby nominate “onion” as the logical HRP for RFC 7686 .onion 
special-use domain names.


Here is Bech32 .onion by example, using my bech32 tool with its built-in 
.onion support to encode and decode the name for the Tor Project’s 
.onion equivalent of its “www” site:


```
$ bech32 -e expyuzz4wqqyqhjn.onion
onion1yh0c5eeuksscs8fdyd8406
$ bech32 -d onion1yh0c5eeuksscs8fdyd8406
expyuzz4wqqyqhjn.onion
```

The string is longer, because it contains 6 base32 characters’ worth of 
error-correcting code.  N.b. also, the foregoing should work just fine 
for v3 onions (formerly prop-224).


Imagine the impact on users who have a practical need to transmit a 
.onion address by verbal communication, or via a handwritten note.  Now 
they can get some help with errors, instead of wondering why they can’t 
connect to a nonexistent .onion site.


The standard enjoins applications against autocorrecting Bitcoin 
addresses, so as to prevent even the slightest possibility of causing 
funds loss by being too “helpful”.  But in applications where it would 
be safe to do so, Bech32 can indeed correct small errors (as well as 
reliably detecting much worse errors).  I suggest that such automatic 
correction would be suitable for .onion addresses.


Bech32 co-author Dr. Wuille (sipa) has published Javascript reference 
code, plus a Javascript error-correction demo, under an MIT license.  
Perhaps this may be easily adapted into Torbutton, for automagic 
decoding of Bech32 “onion1” to .onion domains in the Tor Browser address 
bar.  The code is in the same repository whence I copied the Bech32 
reference C code I use internally in my tool:


https://github.com/sipa/bech32

# Conclusion—or, to be continued...

An alternative representational format with error-correcting codes will 
make .onion addresses more human-friendly.  I look forward to the day 
when “onion1” addresses can be passed by handwritten notes, vocalized 
with a radio alphabet, stuffed into QR codes, scrawled on parchments 
placed in bottles tossed to sea, rocketed into space, and then 
conveniently transformed with appropriate corrections into the DNS-style 
.onion format specified by RFC 7686.


Here’s to the alternative Onion format of the future!

--
null...@nym.zone | PGP ECC: 0xC2E91CD74A4C57A105F6C21B5A00591B2F307E0C
Bitcoin: bc1qcash96s5jqppzsp8hy8swkggf7f6agex98an7h | (Segwit nested:
3NULL3ZCUXr7RDLxXeLPDMZDZYxuaYkCnG)  (PGP RSA: 0x36EBB4AB699A10EE)
“‘If you’re not doing anything wrong, you have nothing to hide.’
No!  Because I do nothing wrong, I have nothing to show.” — nullius


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev