[tor-dev] Future Onion Addresses and Human Factors

[David Goulet]

On 08 Aug (11:36:35), 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.

Beers, very nice! :)

[snip]

> 
> 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

That I like quite a bit!

Right now, with the 16 char address, I doubt very much that people
actually type them in the browser, I bet it's still and will continue to
be Copy-Paste. As for the verification part that is making sure you have
the right .onion, I'm pretty sure this is just ignore by most users and
that it is actually worst with vanity address because as long as I see
"facebook" in there, that's good enough. Ok, you guys have a pretty epic
one that is quite noticeable but let's take Wikileaks upload page for
instance "wlupld3ptjvsgwqw.onion", only seeing "wlup" is MOST probably
way enough for most of the users and 12 characters are then ignored.

(Altough, most users probably rely on the CA-mafia to get their .onion
in a "trusted" ways so anycase the "verification of .onion" situation is
pretty bad. ;)

With "banks of char", it makes it much more easier for someone to
remember one of them and verify that at least the one I remember is
there. It's not perfect but it's a damn good start imo. I remember
reading a while back a study about research done at Bell Labs when they
were trying to come up with a standard length for the phone numbers in
North America (now 7 digits + 3 area code). One of the reasons in the
end was the human brain capability of quickly, and for a reasonable
amount of time, remembering <= 7 digits.

So, this approach takes advantage of that "human brain quirk" and we
should definitely use it to improve onion address verification by users.
With 52 characters, there could be 7 blocks of 7 chars (49) and a last
block of 3 chars + the 4 unused bits (see below for those). If you
remember at least one of those blocks somewhere in the string, I say
amazing improvement!

(I would NOT go with different length though, I bet *everyone* will end
up remember the smallest one so have them at least all the same length
or some of them bigger.)

> 
> 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

See section 1.2 of proposal 224 (NOT 244 ;), there are 4 unused bits
when using base32 encoding. I remember we had a discussion about those
at the HS meeting [1], ideas where the length, very small checksum ("a
la credit card"), or human readable word.

So definitely, this needs to be clarified in the proposal.

> 
> 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.  :-)

Totally and if by some email magic we reach a concensus, this should be
added to the prop#224 before we do implement it. (Or even it's own
proposal if too big.)

Cheers!
David

[1] https://blog.torproject.org/blog/hidden-service-hackfest-arlington-accords

> 
>     - alec
> 
> 
> —
> Alec Muffett
> Security Infrastructure
> Facebook Engineering
> London
> 



> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150808/f08c3976/attachment.sig>