[tor-dev] Future Onion Addresses and Human Factors

Alec Muffett alecm at fb.com
Sat Aug 8 11:36:35 UTC 2015

Hi All,

Having Beer with Donncha, Yan and others in Berlin a few days ago, discussion moved to Onion-Address Human Factors.

Summary points:

1) it’s all very well to go an mine something like “facebookcorewwwi” as an onion address, but 16 characters probably already exceeds human ability for easy string comparison.

2) example of the above: there are already “in the field” a bunch of onion addresses “passing themselves off” as other onion addresses by means of common prefixes.

3) next generation onion addresses will only make this worse

4) from Proposal 244, the next generation addresses will probably be about this long:


5) taking a cue from World War Two cryptography, breaking this into banks of five characters which provide the eyeball a point upon which to rest, might help:


6) using underscores would be a pain (tendency to have to use SHIFT to type)

7) using dots would pollute subdomains, and colons would cause parser confusion with port numbers in URIs

8) being inconsistent (meaning: “we extract the second label and expunge anything which is not a base32 character”, ie: that with-hyphens and without-hyphens) may help or hinder, we’re not really sure; it would permit mining addresses like:

	agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion # illustration purposes only

…which *looks* great, but might encourage people to skimp on comparing [large chunks of] the whole thing and thereby enable point (2) style passing-off.

9) appending a credit-card-like “you typed this properly” extra few characters checksum over the length might be helpful (10..15 bits?) - ideally this might help round-up the count of characters to a full field, eg: XXX in this?


10) it might be good to discuss this now, rather than later?

Hence this email, in the hope of kicking off a discussion between people who care about human factors.  :-)

    - alec

Alec Muffett
Security Infrastructure
Facebook Engineering

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150808/003b7f60/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150808/003b7f60/attachment.sig>

More information about the tor-dev mailing list