[tor-dev] Future Onion Addresses and Human Factors

[Jeff Burdges]

> On Sat, Aug 08, 2015 at 11:36:35AM +0000, Alec Muffett wrote: 
> > 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

We could make the .onion URL human recognizable, but not actually human
typeable.  I like key poems : 
https://moderncrypto.org/mail-archive/messaging/2014/000125.html

In fact, there is no need to conceptualize this as a URL except for
convenience.  We could provide a .onion key poem library so that TBB,
etc. can display them when you mouse over the URL bar.


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

There are a couple choices for mappings for the non-essential characters
in base 32 encodings.  I believe the usual one was designed to make
spelling fuck impossible or some stupidity like that.  I think the one
GNUNet uses was selected to provide as much flexibility as possible.
It's no worse for type-o squating if u and v map to the same value and a
few similar things.


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

Yes, checksums help enormously.

Interestingly, there are situations where you're entering a password,
but the machine should add a checksum while remaining human readable.  

In those situations, there is a clever suggestion by Christian Grothoff
that an algorithm tweak the human readable passphrase until some hash is
zero.  

Pond's PANDA key exchange is an example of when one should do this,
although Pond does not.

I doubt that's relevant for .onion URL itself, but maybe worth
considering for vanity key poems or something. 


On Sat, 2015-08-08 at 09:05 -0400, Roger Dingledine wrote:
> I'm a fan:
> https://trac.torproject.org/projects/tor/ticket/15622
> 
> Though I fear my point in the ticket about the Host: header might be
> a good one.

A priori, "pet names" sounds vaguely like the GNU Name System (GNS),
meaning short names consistent for the user, but not globaly unique. 

In GNS, there is a .short.gnu domain so that after you visit facebook's
blah.zkey then facebook.short.gnu becomes a meaningful domain.  I'd
worry however that, if your anti-facebook friend jake sets his preferred
short name to facebook, and you visit his zone fist, then he gets
facebook.short.gnu on your machine.  TOFU world problems.  ;)


On Sat, 2015-08-08 at 08:44 -0400, Paul Syverson wrote:
> 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

OnioNS has a relatively weak adversary model, like Namecoin, right?
It's certainly plausible that's good enough for most users, including
all financial users, but maybe not everyone.  

There are several approaches to improving upon that adversary model :

- Pinning in the Name System - If a name X ever points to a hidden
service key, then X cannot be registered to point to a different hidden
service key for 5 years.  Alternatively, if our name system involves
another private key, then X cannot be registered under another private
key for 5 years. 

- Pinning/TOFU in the browser - If my browser ever visits X then it
locks either the .onion key and/or the TLS key permanently.
Alternatively pin both but one at a time to change.  Sounds bad for
Tails, etc. though.

- Awareness - Just yell and scream about how OnioNS, Namecoin, etc. are
nowhere near as secure as a .onion address.  And especially tell anyone
doing journalism, activist, etc. to use full .onion addresses.

- Key Poems maybe?

Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150809/fb7afb98/attachment.sig>