[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Future Onion Addresses and Human Factors
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:
>
> 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:
>
> a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion
>
> 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:
>
> a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sd.onion
>
> 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?
>
> a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion
>
> 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. :-)
>
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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev