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

[Matthew Finkel]

On Fri, Jun 07, 2013 at 02:23:55AM -0400, grarpamp wrote:
> >> This has the side effect of promoting good onion upkeep.
> 
> Which people might be loathe to do given the recent paper
> about deanon hidden services seeming to be relatively doable.
> At least until those issues are solved...
> 
> > of the system. After 6 months (or so) the naming will stabilize and be
> > (mostly) consistent month-to-month, but how do we guarantee that a
> 
> ...not if people are replacing their network address every month.
> 

This shouldn't be a problem if the service id (onion address) remains
the same across IP address changes. If the HS is stable then, as far as
I understand this system, it should maintain its name.

> > I know very little about eepsites, but as long as the guarantees
> > provided by eepsites and HS are equivalent regarding security and
> > anonymity, this is an interesting idea. The easiest/obvious way to
> > accomplish this is to have gateways/peering-points between the two
> > networks
> > ...
> > Unless, are you talking about running I2P and Tor on the same
> > computer/network and being able use the same naming scheme to connect to
> > both eepSites and Hidden Services?
> 
> One such obvious scheme that exists today is your host simply
> routing packets out its tunnel interfaces resident on respective
> Tor / I2P / Phantom IPv6 address space to some such services.
> 
> Then anything, or set of things with unique addressing amongst
> them, can have some petname layer on top.

Sure

> 
> > malicious actor is not able to register popular internet domains
> > (torproject, ddg, etc) before the legitimate/honest actor?
> 
> Really? Lol. You're not going to solve that even if you recreate
> the non-anonymous internet. Petname strings in an anonymous
> censor free system have no gatekeepers. As with the internet,
> users will set up, choose, and duke it out in their own DNS for that
> if they want it... on top of the provided secure network addressing.
> 
> Even being able to put/maintain *any* name out there will be hard.

Right, which is why I'm not sure a centralized naming system will work
in this environment. 1) The user loses the self-authentication of the
service (whether or not they understood they had it in the first place).
2) It's not possible to guarantee a name maps to the same hidden service
over long periods (see 1.) and if trust in placed in the name then this
is important. If I visit https://google.com I expect not to be MITMd
and I expect to receive a reply from Google Inc's webserver.