Re: [tor-dev] Memorable onion addresses (was Discussion on the crypto migration plan of the identity keys of Hidden Services)

[Matthew Finkel <matthew.finkel@xxxxxxxxx>]

I liked the new subject, so I'm sticking with it. :)

On Sun, May 19, 2013 at 04:37:22AM -0700, George Kadianakis wrote:
> > adrelanos:
> >> George Kadianakis:
> >> I don't know if the petname system is an completely orthogonal issue or
> >> if it could be considered when you decide this one.
> >>
> >> >> Or have an option for maximum key length and a weaker default if
> >> common
> >> >> CPU's are still too slow? I mean, if you want to make 2048 bit keys
> >> the
> >> >> default because you feel most hidden services have CPU's which are
> >> too
> >> >> slow for 4096 bit keys, then use 2048 bit as default with an option
> >> to
> >> >> use the max. of 4096 bit.
> >> >>
> >> >> Bonus point: Can you make the new implementation support less painful
> >> >> updates (anyone or everyone) when the next update will be required?
> >> >> (forward compatibility)
> >> >
> >> > I was also trying to think of a solution to this problem, but I
> >> failed.
> >
> > I think you were heading in the right direction with the petname idea.
> > What if we deployed a potentially shitty naming layer that "probably"
> > won't break within the next 6-12 months, but *might* last quite a bit
> > longer than that, for backward compatibility purposes.
> >

So I think we should make some terms clear (just for the sake of
clarity). We have, I guess, three different naming-system ideas
floating here: petnames, (distibuted) namecoin-ish, and centralized
consensus-based - rough summary.

Some months ago, the petname system interested me enough that I started
to write a proposal for it. At this point, it's wound up in bitrot.
Though I'd spent a bit of time working on it, there was no comprehensive
way to accomplish it. One thing to remember about petnames is that they
are *user defined*. It's a system where Alice gives Bob some-name and
Bob assigns it a name (the same name or a different one) which he will
forever know is mapped to that name Alice gave him. The advantage to this
is that forgery is nearly impossible because if Eve gives Bob a name and
tells him it's the same name that Alice gave him, the petname system
will be a verifier - without requiring Bob to remember the name Alice
gave him. In addition, Alice can give Bob idnxcnkne4qt76tg.onion and
Bob can map that to 'torproject' and he is now forever able to access it
using this memorable name. The only race condition in this system is
Bob's Trusted Party from which he obtains the original address.

The problem I ran into with this scheme is where the mappings should be
stored - who is in control of this? In short, is this a mapping that Tor
persistently stores or is it a client application that handles this. AND
if it is a client application, that becomes a usabibility nightmare
because if Tor Browser has an interface for it, then that's great but
what if I'm using irssi and lynx on a headless system? If Tor maintains
this database, then for the petname to perform as expected, every
application would need to support a minimal Controller and have the
ability to resolve the name mappings (and possibly append to them,
also).

For the other naming-system options, also see
proposals/ideas/xxx-onion-nyms.txt and proposals/194-mnemonic-urls.txt
in torspec, if you haven't already. 

> > In terms of verification, it would be trivial to alter the browser UI to
> > display the actual key behind the hidden service (ie: through a control
> > port lookup command and some kind of URL icon that varied depending on
> > consensus naming status).
> >

Yeah, this would definitely be important to have, in any mapping-scheme.

> > We could also provide a hacked version of CertPatrol that monitors the
> > underlying public keys for you, and it would also be relatively easy to
> > add a "second-look" authentication layer through the HTTPS-Everywhere
> > SSL Observatory, similar to what exists now for SSL public keys.
> >
> > In fact, if we can agree on a solid consensus-based naming scheme as a
> > valid transition step, I think it is worth my time to let the rest of
> > the browser burn while I implement some kind of backup authentication +
> > UI for this. After all, memorable hidden service naming would be a
> > usability improvement.
> >

No doubt :)

> >
> > Should we try it?
> >
> > The major downside I am seeing is PR fallout from the hidden services
> > that chose to use it.. They might be a unrepresentative subset of what
> > actually people need hidden services for. I think the real win for
> > hidden services is that we can turn them into arbitrary private
> > communication endpoints, to allow people to communicate in ways that do
> > not reveal their message contents *or* their social network. There
> > probably are other uses whose promise would be lost in the noise
> > generated from this scheme as well...
> >

Regarding PR fallout, I think that whichever scheme is chosen, it *can not*
be a "managed" system. Anything involving a select few nodes generating a
consensus where a "blacklist" can influence the results will be detrimental.
However, on the flip-side, it must be a trustable system.

> (I forked the thread, since this is hopefully orthogonal to HS identity
> key migration.)
> 
> Chuff chuff! Train of thought coming up, since this is a problem I've also
> been thinking about lately...
> 

Chuff chuff? Is that like Choo Choo for those of us in the States? :)

> Mike, I like the simplicity and implementability of your idea. Giving
> signed (<name> to <onion address>) mappings to the directory authorities
> (in a FIFO fashion) and then publishing them as a directory documents is
> effective and easy-ish both to implement and understand.

I also really like the simplicity of this idea, but I worry about any
FUD that may be spread if it doesn't work *exactly* the way "some user"
expects it to work.

> 
> That said, I wonder what's actually going to happen if we implement and
> deploy this. I imagine that scammers will try to win the race-condition
> against the legitimate hidden services, and they will flood the directory
> with false mappings. For example, scammers might claim all memorable names
> for the Tor website hidden service, like "torproject" "torpoject1" etc.
> (and I doubt that anyone can win a race against a well equipped
> scammer...) In the end, many legit hidden services might need to register
> names like "t0rproj3ct1" and "123duckduckg0" which will be lost in the
> noise of that directory document. Then people might think that searching
> for "torproject" in the TBB petname tool ought to return the official
> torproject website, but instead the first results will be scammer
> websites.
> 

Being able to trust the results will be of the utmost importance, or
else the entire system will be a waste.

> Of course, the current situation, where people get their onions using
> pastebins and the "Hidden Wiki" (lulz), is not any better. Although I hope
> that when all URLs look random, people don't consider a URL being more
> official than other URLs (whereas in the above idea "torproject" might
> look a bit more official than "t0rpoj3ct"). Still, even with a current
> situation, a shallot-generated "torpr0jectkakqn.onion" might look more
> official than "idnxcnkne4qt76tg.onion" (which is the actual onion address
> for the torproject website)... I really don't know what's the best way to
> proceed here, it's tradeoffs all the way down.
> 
> If I could automagically generate secure technologies on a whim, I would
> say that some kind of decentralized reputation-based fair search engine
> for hidden services might squarify our Zooko's triangle a bit.
> "decentralized" so that no entities have pure control over the results.
> "reputation-based" so that legit hidden services flow on top. "fair" so
> that no scammers with lots of boxes can game the system. Unfortunately,
> "fair" and "reputation-based" usually contradict each other.
> 
I think yes-and-no, depending on the context. It may actually be
possible, if not necessary, to use a reputation-based system if we also
want the assignments to be fair. At face value, I would take 'fair' to
mean that if Alice and Bob both request 'HiddenWiki' at approximately
the same time, then they both have a 50% chance of obtaining that
assignment. However, if Bob has been given that name for the last 3
months, I would expect that Bob would have a much higher probability of
receiving that mapping. I think, along this same line of thought, that
initialization of this system may be a difficult problem, the necessity
of ensuring it's trustable at first-launch.

- Matt
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev