[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" <nullius at nym.zone> 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!
>
> --
> nullius at 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
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171231/5d071238/attachment.html>