> 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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev