[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!

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20171231/caae2f1c/attachment.sig>