Hi Alec,
On Sat, Aug 08, 2015 at 11:36:35AM +0000, Alec Muffett wrote:
Hi All,
Having Beer with Donncha, Yan and others in Berlin a few days ago, discussion moved to Onion-Address Human Factors.
Summary points:
- 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.
- 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.
next generation onion addresses will only make this worse
from Proposal 244, the next generation addresses will probably be
about this long:
a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion
- 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:
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sd.onion
- using underscores would be a pain (tendency to have to use SHIFT
to type)
- using dots would pollute subdomains, and colons would cause
parser confusion with port numbers in URIs
- 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.
- 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?
a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion
- 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. :-)
These are all good points. Not sure you are so much kicking off as joining some discussions. Maybe you will help pull several discussions into some sort of coordination. Anyway, I would say that there have been broadly two approaches to human factors and onion addresses which the above should complement well.
One is to produce human meaningful names in association with onion addresses. Coincidentally Jesse has just announce to this same list a beta-test version of OnionNS that he has been working on for the Tor Summer of Privacy. See his message or
https://github.com/Jesse-V/OnioNS-literature
The other that I am aware of is to bind onion addresses in a human meaningful way to existing names, typically registered domain names, but could be e.g. a Facebook page rather than a domain name per se. A preliminary description of this can be found in "Genuine onion: Simple, Fast, Flexible, and Cheap Website Authentication". Both paper and slides pdf can be found under http://ieee-security.org/TC/SPW2015/W2SP/
I have since that presentation been talking to Let's Encrypt folk and others about ways to expand and revise the ideas therein. Some of us have also worked on a related Tor Proposal on single onion services (aka direct onion services vs. location-hidden aka double onion services) that would be posted if I could ever find time to just add a little more to make it self-contained. We expect to have a revised and expanded version of the above paper in the not too distant future. (This week I'll be giving a course about Tor at the SAC Summer School and the Stafford Tavares Lecture at SAC in New Brunswick, but will be almost completely skipping onion services since there is basically infinite amounts of Tor things to talk about.) Picking this up again significantly in about a week and a half or thereabouts.
aloha, Paul