[tor-dev] Prop-279 for Onion Alternative Name Representations (Re: Error-Correcting Onions with Bech32)

[nullius]

On 2017-12-31 at 14:23:39 +1100, teor <teor2345 at gmail.com> wrote:
>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.)

Thanks, teor.  I reviewed the spec (version 13cbcbc) carefully, and 
opened https://trac.torproject.org/24774 attaching a `git diff` patch 
with proposed changes.

The crux of the matter is support for what I will call alternative name 
representations.  Prop-279 assumed quasi-DNS names resolved through some 
sort of a network or database lookup.  However, an alternative 
representation can be entirely self-contained.  Thus, one of the changes 
I request is to explicitly permit a global wildcard '*' tld for plugins 
which can be sandboxed with neither network nor filesystem access (and 
will return answers in microseconds).

I also proposed changes to permit the UTF-8 characters required for 
representing names in languages other than American English, and some 
other technical improvements.  I added status code 5 to support plugins 
which can discern when a name is in a recognized format, but is 
intrinsically invalid e.g. due to checksum failure; and I expanded the 
description of status code 2, for plugins which do not have TLDs but do 
recognize a definite syntax.

The potential use cases here extend beyond my suggestion for 
Bech32-coded .onions.  I also wish to encode .onion addresses in a 
mnemonic phrase, similar to those generated by this tool:

easyseed(1) BIP 39 mnemonic phrase generator
https://github.com/nym-zone/easyseed
manpage:
https://raw.githubusercontent.com/nym-zone/easyseed/master/easyseed.1.txt

Out of the box, that will make a mnemonic from the raw data for a v3 
.onion address, but not v2 (too short).  I could easily draw up a spec 
to represent v2 .onions as 8 words, and v3 onions as 24–25 words, each 
including a simple checksum.  The mnemonic standard I’ve been using 
includes carefully designed wordlists for nine different languages; I 
will soon be adding multilanguage support to my tool, which I could copy 
over to a prop-279 name system plugin.

Now, imagine an activist under a repressive régime whispering in the ear 
of a whistleblower eight words for the address of a SecureDrop.  Or 
scrawling a Bech32 address on a scrap of paper in a hurry.  The 
possibilities are many.

Should my proposed changes be accepted, I will be eager to write tools 
and plugins for .onion alternative representations which look either 
like this (a real address, properly encoded in Bech32):

	onion1kt50trm0nf4jxkskpcjy74

...or approximately like this (random words off a wordlist, for example 
only):

	mad century mirror awkward glory shine cake fat

...with out-of-the-box support for Chinese (Simplified), Chinese 
(Traditional), French, Italian, Japanese, Korean, and Spanish, in 
addition to English.

Wordlists, all designed to minimize user error:
https://github.com/bitcoin/bips/tree/master/bip-0039
(In the English list, all words are unique within the first four 
characters; and similar/confusable words are excluded.)

Given appropriate prop-279 changes, I won’t need to draw a proposal.  
I’ll simply write code!

-- 
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/1dcf1898/attachment.sig>