[tor-dev] Prop-279 for Onion Alternative Name Representations (Re: Error-Correcting Onions with Bech32)
nullius at nym.zone
Sun Dec 31 10:12:53 UTC 2017
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:
>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
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):
...or approximately like this (random words off a wordlist, for example
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:
(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...
Size: 228 bytes
Desc: not available
More information about the tor-dev