Cooking With Onions: Names for your onions

by asn | April 4, 2017



Hello again,

this blog post is the second issue of the Cooking with Onions series which aims to highlight interesting aspects of the onion space. Check-out our first issue as well!

Onion addresses are weird...

This post is about onion addresses being weird and the approaches that can be taken to improve onion service usability.

In particular, if you've cruised around the onionspace, you must have noticed that onion services typically have random-looking addresses that look like these:

  • 3g2upl4pq6kufc4m.onion
  • 33y6fjyhs3phzfjj.onion
  • propub3r6espa33w.onion

So for example, if you wanted to visit the Tor website onion service, you would have to use the address http://expyuzz4wqqyqhjn.onion/ instead of the usual https://www.torproject.org.

To better understand why onion addresses are so strange, it helps to remember that onion services don't use the insecure Domain Name System (DNS), which means there is no organization like ICANN to oversee a single root registry of onion addresses or to handle ownership dispute resolution of onion addresses. Instead, onion services get strong authentication from using self-authenticating addresses: the address itself is a cryptographic proof of the identity of the onion service. When a client visits an onion service, Tor verifies its identity by using the address as ground truth.

In other words, onion services have such absurd names because of all the cryptography that's used to protect them. Cryptographic material are basically huge numbers that look meaningless to most humans, and that's the reason onion addresses tend to look random as well.

To motivate this subject further, Tor developers have medium-term future plans for upgrading the cryptography of onion services, which has the side-effect of increasing onion address length to 54 characters! This means that in the future onion addresses will look like this:

  • llamanymityx4fi3l6x2gyzmtmgxjyqyorj9qsb5r543izcwymlead.onion
  • lfels7g3rbceenuuqmpsz45z3lswakqf56n5i3bvqhc22d5rrszzwd.onion
  • odmmeotgcfx65l5hn6ejkaruvai222vs7o7tmtllszqk5xbysolfdd.onion

Remembering onions

Over the years the Tor community has come up with various ways of handling these large and non-human-memorable onion addresses. Some people memorize them entirely or scribe them into secret notebooks, others use tattoos, third-party centralized directories or just google them everytime. We've heard of people using decks of cards to remember their favorite onion sites, and others who memorize them using the position of stars and the moon.

We believe that the UX problem of onion addresses is not actually solved with the above ad-hoc solutions and remains a critical usability barrier that prevents onion services from being used by a wider audience.

The onion world never had a system like DNS. Even though we are well aware that DNS is far from the perfect solution, it's clear that human memorable domain names play a fundamental role in the user experience of the Internet.

In this blog post we present you a few techniques that we have devised to improve the usability of onion addresses. All of these ideas are experimental and come with various fun open questions, so we are still in exploration mode. We appreciate any help in prototyping, analyzing and finding flaws in these ideas.



Idea 1) A modular name system API for Tor onion services

During the past years, many research groups have experimented and designed various secure name systems (e.g. GNS, Namecoin, Blockstack). Each of these systems has its own strengths and weaknesses, as well as different user models and total user experience. We are not sure which one works best for the onion space, so ideally we'd like to try them all and let the community and the sands of time decide for us. We believe that by integrating these experimental systems into Tor, we can greatly strengthen and improve the whole scientific field by exposing name systems to the real world and an active and demanding userbase.

For this reason and based on our experience with modular anti-censorship techniques, we designed a generic & modular scheme through which any name system can be integrated to Tor: Proposal 279 defines A Name System API for Tor Onion Services which can be used to integrate any complex name system (e.g. Namecoin) or even simple silly naming schemes (e.g. a local /etc/tor-hosts file).

Here is a graphical depiction of the Name System API with a Namecoin module enabled and resolving the domain sailing.tor for a user:


It's worth pointing out that proposal 279 is in draft status and we still need to incorporate feedback received in the mailing list. Furthermore, people have pointed out simple ways through which we can fast-track and prototype the proposal faster. Help in implementing this proposal is greatly appreciated (find us in IRC!).

Idea 2) Using browser extensions to improve usability

Other approaches for improving the usability of onion addresses use the Tor Browser as a framework: think of browser extensions that map human memorable names to onion addresses.

There are many variants here so let's walk through them:

Idea 2.1) Browser Extension + New pseudo-tld + Local onion registry

A browser extension like HTTPS-everywhere, uses an onion registry to map human-memorable addresses from a new pseudo-tld (e.g. ".tor") to onion addresses. For example, it maps "watchtower.tor" to "fixurqfuekpsiqaf.onion" and "globaleconomy.tor" to "froqh6bdgoda6yiz.onion". Such an onion registry could be local (like HTTPS-everywhere) or remote (e.g. a trusted append-only database).

Even an extension with a local onion registry would be a very effective improvement to the current situation since it would be pretty usable and its security model is easy to understand: an audited local database seems to work well for HTTPS-everywhere. However, there are social issues here: how would the onion registry be operated and how should name registrations be handled? I can see people fighting for who will get bitcoin.tor first. That said, this idea can be beneficial even with a small onion database (e.g. 50 popular domains).

Here is a graphical depiction of a browser extension with a local onion registry resolving the domain sailing.tor for a user:



Idea 2.2) Browser extension + New pseudo-tld + Remote onion registries

A more dynamic alternative here involves multiple trusted remote onion registries that the user can add to their torrc. Imagine a web-of-trust based system where you add your friend's Alice onion registry and then you can visit facebook using facebook.alice.onion.

A similar more decentralized alternative could be a browser addon that uses multiple remote onion registries/notaries to resolve a name, employing a majority or supermajority rule to decide the resolution results. Such a system could involve notary nodes similar to SSL schemes like Convergence.

Idea 2.3) Browser extension redirects existing DNS names

An easier but less effective approach would be for the browser extension to only map DNS domain names to onion names. So for example, it would map "duckduckgo.com" to "3g2upl4pq6kufc4m.onion". That makes the job of the name registrar easier, but it also heavily restricts users only to services with a registered DNS domain name. Some attempts have already been made in this area but unfortunately they never really took off.

Idea 2.4) Automatic Redirection using HTTP

The Alt-Svc HTTP header defines a way for a website to say "I'm facebook.com but you should talk to me using fbcdn.com." If we replace that fbcdn.com address with facebookcorewwi.onion - then when you typed in Facebook, the browser would, under the covers, use the .onion address. And this can be done without any browser extension whatsoever.

One problem is that the browser has to remember this mapping, and in Tor Browser that mapping could be used to track or correlate you. Preloading the mapping would solve this, but how to preload the mapping probably brings us back into the realm of a browser extension.

Idea 2.5) Smart browser bookmarks for onion addresses

Talking about random addresses, it's funny how people seem to be pretty happy handling phone numbers (big meaningless random numbers) using a phone book and contacts on their devices.

On the same note, an easier but less usable approach would be to enhance Tor Browser with some sort of smart bookmark/petname system which allows users to register custom names for onion sites, and allows them to trust them or share them with friends. Unfortunately, it' unclear whether the user experience of this feature would make it useful to anyone but power users.

Of course it's important to realize that any approach that relies on a browser extension will only work for the web, and you wouldn't be able to use it for arbitrary TCP services (e.g. visiting an IRC server)

Idea 3) Embed onion addresses in SSL certificates

So let's shift back to non-browser approaches!

Let's Encrypt is an innovative project which issues free SSL certificates in an automated fashion. It has greatly improved Internet security since now anyone can freely acquire an SSL certificate for their service and provide link security to their users.

Now let's imagine that Let's Encrypt embedded onion address information into the certificates it issues, for clients with both a normal service and an onion service. For example, the onion address could be embedded into a custom certificate extension or in the C/ST/L/O fields. Then Tor Browser, when visiting such an SSL-enabled website, would parse and validate the certificate and if an onion address is included, the browser would automagically redirect the user. Take a look at this paper for some more neat ideas on this area.

Idea 4) Embed onion addresses in DNS/DNSSEC records

A similar approach could use the DNS system instead of the SSL CA system. For example, site owners could add their onion address into their TXT or SRV DNS records and Tor could learn to redirect users to the onion address. Of course this approach only applies to operators that can afford a DNS domain. Oh yeah DNS also has zero security...

Conclusion

As you can see there are many approaches that we should explore to improve usability in this area. Each of them comes with its own tradeoffs and applies to different users, so it's important that we allow users to experiment with various systems and let each community decide which approach works best for them.

It's also worth pointing out that some of these approaches are not that hard to implement technically, but they still require lots of effort and community building to really take off and become effective. Involving and pairing with other friendly Internet privacy organizations is essential to achieve our goals.

Furthermore, we should think carefully of unintended usability and security consequences that come with using these systems. For example, people are not used to their browser automagically redirecting them from one domain to another: this can seriously freak people out. It's also not clear how Tor Browser should handle these special names to avoid SSL certificate verification issues and hostname leaks.

One thing is for sure: even though onion services are used daily by thousand of people, the random addresses confuse casual users and prevent the ecosystem from maturing and achieving widespread adoption. We hope that this blog post inspires researchers and developers to toy around with naming systems and take the initiative in building and experimenting with the various approaches. Please join the [tor-dev] mailing list and share your thoughts and projects with us!

And this brings us to the end of this post. Hope you enjoyed this issue of Cooking With Onions! We will be back soon, always with the finest produce and the greatest cooking tips! What would you like us to cook next?

[Thanks to Philipp Winter and Tom Ritter for the feedback on this blog post, as well as to everyone who has discussed and helped develop these ideas.]

Comments

Please note that the comment area below has been archived.

April 04, 2017

Permalink

Great article! In practice I only regularly visit 3-4 onion addresses (by copy pasting them from onion.txt on my desktop). But I think at least 1/16 of the other sites I visit already have an onion service, but since finding onion services for them and classifying them in my txt file will take more time, I tend to just use the regular websites themselves.

April 04, 2017

Permalink

Your blogs are so much richer when you write about more then just software updates :-) thanks

April 04, 2017

Permalink

Very nice article asn!

One problem though: when I last tested adding specific HTTPS Everywhere rulesets to change addresses to their corresponding onion site (in the specific folder dedicated to user rulesets), it just didn't work. Is it just me or does it no longer work?

if anyone is interested I could share my own list of up-to-date rulesets, I was the major contributor to that project and I currently have around 300 rules which is twice the number in darkweb-everywhere, though many old rules contain dead websites

April 04, 2017

Permalink

Having been around the TLD loop once, may I please suggest that any directory/registry live *beneath* ".onion", for instance:

[geshifilter-code]http://petname.tor.onion/[/geshifilter-code]

...because the prospect of going back to IANA/ICANN and CA/B-Forum with a request for yet another TLD is too horrific to contemplate. :-)

- alec

I don't know if such a thing exists. The proof of work is the whole reason NameCoin works. Clients never have to compute it so I don't think it's a big deal. In fact, there are already some public DNS servers that resolve .bit names (but you have to trust them).

Sorry for not being specific.

Yes, the current vibe is to put everything under .onion .

So if you used Namecoin you would have to go to reddit.bit.onion .
And if you used GNS you would have to go to reddit.gnu.onion .
And if you used MagicalNameSystem you would have to go to reddit.mns.onion .

The idea here is that keeping the .onion TLD is very rewarding for Tor, since we have already registered it with IETF and it's protected. So no one can steal it from us, and also other browsers know that it's special-purpose and they shouldn't leak it to the DNS servers. e.g. see:
https://bugzilla.mozilla.org/show_bug.cgi?id=1228457

April 04, 2017

Permalink

as i understand dark-web-everywhere as in compare to the clear-net https-everywhere... should not be an worry if one trust the end website ? (assuming non-state honeypots)

depend on one own threat model i guess ...hidden to hidden you get the anon anyway... unless of course if one silly enough to give social information e.g with own name etc... and the hidden is an state run hidden service.

April 04, 2017

Permalink

#1 is obviously the best. Okay that might be an overstatement, but really, all the alternatives pale in comparison. They either are browser only, require existing clearnet presence (DNS, PKI), or have real logistics/management hurdles (Zokoo's triangle).

We already have naming systems that are secure, human readable, and globally unique. Why would we bother with the registration politics nightmare of a remote authoritative naming repository? Or many nonauthoritative ones that can have global naming collisions.

NameCoin/GNS/BlockStack might even mainline the client code to make it compatible with Tor. And if not, a small shim would be super simple (disclaimer: I have not read the spec yet). Doesn't NameCoin already have a a record type reserved for .onion addresses?

The answer has been right in front of our faces for at least 5 years now (NameCoin, maybe even others before that). I honestly can't believe it has taken this long to get to where we are, and we're still in the proposal stage. But I'm glad we're getting there! This is a huge step for onion services!

Idea #1 has various unanswered questions that we have not really worked on. For example, see these two posts:
https://lists.torproject.org/pipermail/tor-dev/2016-October/011516.html
https://lists.torproject.org/pipermail/tor-dev/2017-March/012077.html

It does seem like the idea also requires mods to Tor Browser as well, to be able to support SSL certs etc.

Thank you for the links! As usual, the devil is in the details. But just from reading those two posts I can see the problem is not insurmountable. What was getting at is that #1 is the Right Way™ to solve the problem, not the easy way.

April 05, 2017

Permalink

Why not try a system similar to PascalCoin, written in FreePascal.............Just like the nodes who carry Tor bandwidth mirror the directory why not create another directory written like PascalCoin and checked through a Tor directory. I2P is far ahead of Tor in this space, even though Tor has more users.

Sorry this post doesn't make much sense to me.

Why this "PascalCoin"? Does it have anything to do with a name system at all? It would take enornous effort to modify the codebase to work as a name system, as opposed to using an API like NameCoin's. And why does the language matter? Other than the fact that most of Tor devs already use C and JS and not Pascal.

Having the Tor directories do the lookups is an interesting idea. You'd have to trust them, and I don't know what the anonymity implications would be. You could do remote lookups for any other name system, like NameCoin, too.

I2P is not far ahead of Tor here. The I2P name system is actually kind of silly when you look at how it works. It's really nothing more than a remote replicated "hosts" file. It is not globally unique. And it has practical issues, for example names can never be freed for reuse, even if their private key is destroyed. It's a gimmick compared to NameCoin.

Oh, and by the way, a module could use or be based on PascalCoin or anything else. This blog post is about the API that connects Tor to name system modules. How the modules are implemented doesn't really matter. For all intents and purposes, Tor sees PascalCoin the same way as NameCoin.

April 05, 2017

Permalink

Your just gonna have to make 2 directories one for private .Onions and one for .Onions who people post all over the net trying to direct people to. I don't think you can handle both without 2 seperate directories.

Create a public directory and keep the same .Onion system in place now if possible where someone can give their long string .Onion and either post or it keep it private. That seems like the best way to go, but people will want assurance that the public directory is not tampered with...............

April 05, 2017

Permalink

Why you don't explore such an obvious approach to improving usability as various graphical representations of onion addresses? It works for security verification codes in WhatsApp, Telegram etc., it should also work for onion addresses.

- ComodoHacker

Having various graphical representations of onion addresses might be a small step forward but it's far from a proper solution to this problem.

How many QR codes or key poems can you put in your brain? You probably might remember 3 or 4, but then what do you do for all the rest of the onion sites you want to visit?

Also check this old thread:
https://lists.torproject.org/pipermail/tor-dev/2015-August/009302.html

April 05, 2017

Permalink

05.04.2017 10:32:09.000 [NOTICE] Bootstrapped 5%: Connecting to directory server
05.04.2017 10:32:09.100 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server
05.04.2017 10:32:09.300 [NOTICE] Bootstrapped 15%: Establishing an encrypted directory connection
05.04.2017 10:32:09.400 [NOTICE] Bootstrapped 20%: Asking for networkstatus consensus
05.04.2017 10:32:09.400 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
05.04.2017 10:32:09.400 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
05.04.2017 10:32:09.400 [NOTICE] Closing old Socks listener on 127.0.0.1:9150
05.04.2017 10:32:10.300 [NOTICE] Delaying directory fetches: DisableNetwork is set.
05.04.2017 10:32:18.700 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
05.04.2017 10:32:18.700 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
05.04.2017 10:32:18.700 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
05.04.2017 10:32:18.700 [NOTICE] Opening Socks listener on 127.0.0.1:9150
05.04.2017 10:32:18.700 [NOTICE] Renaming old configuration file to "C:\Users\1\Desktop\Tor Browser\Browser\TorBrowser\Data\Tor\torrc.orig.6"
05.04.2017 10:32:19.800 [NOTICE] Bootstrapped 25%: Loading networkstatus consensus
05.04.2017 10:32:20.600 [NOTICE] Bootstrapped 45%: Asking for relay descriptors
05.04.2017 10:32:20.600 [NOTICE] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 5409/7379, and can only build 39% of likely paths. (We have 75% of guards bw, 73% of midpoint bw, and 70% of exit bw = 39% of path bw.)
05.04.2017 10:32:20.700 [NOTICE] Bootstrapped 69%: Loading relay descriptors
05.04.2017 10:32:20.800 [NOTICE] Bootstrapped 74%: Loading relay descriptors
05.04.2017 10:32:21.500 [NOTICE] Bootstrapped 80%: Connecting to the Tor network
05.04.2017 10:32:22.300 [NOTICE] Bootstrapped 90%: Establishing a Tor circuit
05.04.2017 10:32:22.600 [NOTICE] Tor has successfully opened a circuit. Looks like client functionality is working.
05.04.2017 10:32:22.600 [NOTICE] Bootstrapped 100%: Done
05.04.2017 10:32:23.900 [NOTICE] New control connection opened from 127.0.0.1.
05.04.2017 10:32:24.000 [NOTICE] New control connection opened from 127.0.0.1.

April 05, 2017

Permalink

Hello Tor team,

Would it be possible to lift out just the tor dns code, and the nat traversal code for a dns system only? I like tor, but using a hidden service as a distributed and free dns is a superhit!

So in my ideal world, I'd like to have a Tor DNS software package, that enables me to have a constant .onion address for my home server that I can always use, and to avoid having to many hops in between.

I don't need anonymous browsing for my home server, but only an unchanging name.

Anyway, don't know if you have the time and resources to do this, but it would be nice. Thank you for all the good work!

Hey,

check out the 'Single Onion Services' feature. It's a type of onion service with no anonymity on the service-side, so it doesn't use a 3-hop circuit on the service-side which means it should be faster, but still give you the static onion address you are looking for.

It was introduced in tor 0.2.9.8:
https://blog.torproject.org/blog/whats-new-tor-0298

Thank you very much, I wasn't aware of that! =) That's a great option, and the only thing missing is the ability to disable the 3 hops on the client side as well (or perhaps 2 hops since I assume one hop is needed for routing purposes?).

But I can see that there is a possibility to tweak the countries the 3 hops are located in, so I think the performance should be more than enough for most use cases.

Again, thank you for pointing it out. =)

April 05, 2017

Permalink

The latest financial reports for The Tor Project on the website only cover the period through the end of 2014. Do you know when the organization's 2015 and/or 2016 IRS 990 forms or audited financial statements will be made available? Thanks!

April 05, 2017

Permalink

>Idea 2.4) Automatic Redirection using HTTP

This idea is bad because it forces you to use hidden service verion of the website and in case of Facebook if you try to comment on news websites that facebook for comments under their articles you cant comment when you are logged in to facebook's hidden service.

Of course under normal Tor Browser privacy settings you can't comment even if you are logged in to clearnet Facebook website because of cookie isolation but if you enable third party cookies and tracking you can but as I said this doesn't work with Facebook's hidden service.

April 05, 2017

Permalink

Would .tor be the official TLD for plain-text onion names? If so, do you have plans to get ICANN to assign special-use status to the TLD?
Would .tor be eligible for HTTPS certificates? If so, would it support domain validated like Let's Encrypt or EV only.

That said, would the next generation strong .onion addresses support DV certificates, adding the possibility of Let's Encrypt being able to add support per CA/B rules?

.tor was just an example for this blog post.
We have not actually decided what to do about the tld, but we probably gonna go with .onion . So, like .tor.onion, or .bit.onion, etc. Exactly for the reason that ICANN has standarized .onion and we should keep ourselves in that zone (see other comments on this topic).

We are hoping that the CAB forum will allow onion addresses to get DV certificates as well. I think there are some discussions underway right now, but I imagine the next gen onion services will put extra pressure here.

April 06, 2017

Permalink

I am of the opinion that the optimal scheme is one where I'd be able to boot some amnesic OS that includes Tor and type an "onion" address from memory, just like typing facebook.com of microsoft.com. Nothing written down. Nothing to connect an address to me.

Yep, that's also my hope.

I think your dream could be achieved using a number of approaches from this blog post. Of course, a good amount of engineering, integration and UX testing will be needed to make this nice and useable.

April 06, 2017

Permalink

Does setting up an onion service for my website introduce more noise in the network than just using regular HTTPS?

The circuits people create will be longer, so there will be a little more traffic in the network.

However, the big advantage is that onion service circuits don't use exits nodes. Exits are in short supply.

If you don't need to to hide the location of your website, you could consider setting it up as a single onion service to shorten the circuit length and make it a little faster.

April 07, 2017

In reply to pastly

Permalink

Thank you!

April 06, 2017

Permalink

Problem in idea 1: who decide that john.onion (or john.tor) go to randomaddress1.onion and not to randomaddress2.onion?

If all is anonymous, who can guarantee that microsoft.onion (or microsoft.tor) is really microsoft and not a malicious site?

April 06, 2017

Permalink

Hey guys,

there already exists a working DNS system for TOR which is based on Namecoin technology. It's called 611 and is an open source project on GitHub:
https://github.com/fflo/sixeleven

If you like it you can join the discussion on:
https://bitcointalk.org/index.php?topic=1235629.0

Registered domain objects are reachable under the anonymous domain YOURNAME.611.to, like

  • http://gnupg.611.to (The GNU Privacy Guard)
  • http://thw.611.to (The Hidden Wiki)
  • Using the Qt "611 - Wallet" it's very easy and intuitive to manage your domain name objects

    Screenshots with short description of the additional wallet features are available on this website: https://flo.sh/611-sixeleven/

    Moreover 611 already offers additional TOR services. You can use it to publish an onion website for both: TOR and non-TOR users by using a free service.

    The websites examples above i.e. are also reachable for non-TOR users using a Tor2Web proxy.
    TOR users should be automatically redirected to the matching onion website.

    As the whole project is blockchain based on Bitcoin technology you can always check the validity of the published information using an extended Blockchain Explorer at https://be.611.to

    Let me know if there is anything missing for you :)

    April 06, 2017

    Permalink

    Namecoin as it stands requires users to download a blockchain to use it, this is very stupid. I will never download a blockchain, not for any coin or reason, at least not through Tor.

    Centralized registries are also stupid, this makes the registrar liable, might as well just petition icann to handle all of this.

    We would need a decentraized dns free of blockchain bloat. It seems like the existing onion addressing and network handling already works to this advantage except that it relies on the fact that no two names will ever collide. In which case why not allow people to register collisions then use existing onion network measurement tools to determine the popularity of sites, returning them in the same way a search bar returns autosuggestions.

    Awesome!

    Thanks for your post. Never heard of such a thing.

    For privacy reasons it would be great if the DNS information of the blockchain could be integrated into the tor network, so that it is not necessary to access the public nameserver out of the tor network.

    You could run a local instance of NameCoin and the module could query that. I don't see how Tor could integrate the DNS info into the network in a way that would justify the effort.

    I disagree with your opinion.

    Blockchain technology is perfect for this purpose as it provides a maximum transparent and secure way to resolve the issues discussed.

    As a user you do not have to download the whole blockchain (which is also no big mess for a blockchain containing the DNS system of Tor; it's mainly static data); you can work with a pruned blockchain or use a web based service.

    Setting up a tiny fee on each DNS modification prevents massive abuse as no-one likes to burn money. That's perfect for an anonymous network like Tor.

    A public blockchain explorer containing all confirmed blockchain operations is like a public dictionary offering a level of trust for every user.

    Tor is only missing an interface providing direct access to the public DNS data of Namecoin or 611 so that it's not necessary to poll external DNS servers (which can be subject to external influence) to resolve domain names stored in the blockchain.

    Why should a user have to download a blockchain to use it?

    The blockchain (or using the wallet) is only necessary to setup or update a domain name alias for an onion address.

    The user only resolves the valid onion address alias using dns.

    NameCoin doesn't work without the blockchain. Zokoo's triangle is a hard problem, and it just so happens NameCoin is one of the very few things (maybe the only thing) that actually solves it. We would all like a globally unique, secure, and human readable naming system that doesn't require the user to download a blockchain... we're just waiting for it to be invented at the moment.

    This blog post made it pretty clear that the traditional .onion addresses aren't going anywhere, although they may be increased to 54 characters. All of these proposals are extensions on top of that. Idea #1 allows for many different naming system modules to be used, so you can just use the ones you like the best. Nobody is forcing anyone to use anything.

    I would prefer to use the NameCoin fork 611 or to setup a new fork of it allowing to resolve onion names globally for non-TOR users, too.

    This would widely push the acceptance of hidden onion based web services if these can be reached with web2tor gateways from any Internet device, too.

    As a side effect the fork 611 is almost unknown by now which allows the registration of almost any domain name you like.

    611.to resolves from any Internet capable device.

    Who controls the blockchain?
    Does some entity hold more than 50% in terms of computing power?

    I am sure, blockchain is _not_ the technology we want for our DNS thingy.

    >It seems like the existing onion addressing and network handling already works to this advantage except that it relies on the fact that no two names will ever collide.
    If onion names are secure, collision should be cryptographically hard to achieve. In other words, if you can create collisions they are broken in the first place and should be ditched all together.

    >In which case why not allow people to register collisions then use existing onion network measurement tools to determine the popularity of sites, returning them in the same way a search bar returns autosuggestions.
    Because that entails all kinds of implementation problems plus security and privacy issues.

    Why dishonest?

    The mining rewards of 611 coin are not hidden; it's full open source on GitHub:

    https://github.com/fflo/sixeleven/blob/master.611/src/611.cpp [line 204]
    int64 GetNetworkFee(int nHeight)
    {
    // Speed up network fee decrease 4x starting at 24000
    // if (nHeight >= 24000)
    // nHeight += (nHeight - 24000) * 3;
    // if ((nHeight >> 13) >= 60)
    // return 0;
    // int64 nStart = 50 * COIN;
    // if (fTestNet)
    // nStart = 10 * CENT;
    // int64 nRes = nStart >> (nHeight >> 13);
    // nRes -= (nRes >> 14) * (nHeight % 8192);
    // return nRes;
    // the standard network fee is 6.11 cent
    int64 nStart = 611 * CENT / 100;
    // it will decrease by factor two every 2^18 or 262144 blocks
    int64 nNetFee = nStart >> (nHeight >> 18);
    nNetFee -= (nNetFee >> 19) * (nHeight % 262144);
    // but is was fixed for the very early developers
    if (nHeight <= 10110)
    nNetFee = 611 * CENT / 100;
    if (nHeight <= 2880)
    nNetFee = 611 * CENT / 1000;
    if (fTestNet)
    nNetFee = 1 * CENT;
    return nNetFee;
    }

    All transactions (and even the name operations) can be checked with the 611 Block Explorer: https://be.611.to

    611 is up and running perfectly stable since 2015. As far as I know the DNS service had no downtime since 2015!

    Dev is still actively developing this coin with a good level of trust at BCT.
    611 is trading at a stable level since months on https://www.c-cex.com/?p=611-btc

    I agree with you that 611 coin should be traded with cautiousness, but that's not the topic of this blog post.

    As a crypto coin based DNS, 611 is up and running great since almost two years. As far as I know there is no other crypto coin based DNS supporting any Internet connected device at almost no cost.

    April 09, 2017

    Permalink

    Very useful blog!Thank you!But I am wondering why some onion domain names have special words for example hansa ,it's onion domain name is hansamk2bizhmib4.onion. How this work?

    April 09, 2017

    Permalink

    yeah, 611 works great as a dns resolver for onion websites. For privacy reasons a direct Tor api integration would be nice.

    Is there a need for a short howto/wiki?

    April 09, 2017

    Permalink

    I don't think Tor should do anything. It should be up to the user to verify that they aren't being phished like regular DNS. User-friendly isn't an issue either as everyone bookmarks URLs or has them saved somewhere. These new features would make an already complex system even more complex which worries me as the implementation may have an unknown vulnerability somewhere. However, the developers clearly want to do something about this "issue". If I were in the position to choose, I would go with Idea 1) "A modular name system API for Tor onion services". A lot of questions remain but I trust that the developers will make the right decisions.

    April 10, 2017

    Permalink

    I have mined some 611, so if someone likes to try it out to publish Tor-onions with 611 I'm happy to share some SILs. Share your 611 address.

    April 12, 2017

    Permalink

    Could the outcome of the French presidential election adversely affect Tor users? Would Tor Project be considered a US "tech company"?

    techdirt.com
    Moderate French Presidential Candidate Suggests He May Pressure US Tech Companies Into Creating Encryption Backdoors
    from the safety-through-insecurity dept
    12 Apr 2017

    > France's presidential election season has kicked in. The supposed "moderate" of the bunch -- Emmanuel Macron -- has managed to gain considerable support in the last several months. Some of this has sprung from our own recent election. Earlier this year, the candidate took digs at Trump's anti-climate change stance, stating France would welcome dejected US scientists with open arms.

    April 13, 2017

    Permalink

    >One problem is that the browser has to remember this mapping, and in Tor Browser that mapping could be used to track or correlate you.
    Indeed you should never let websites access your "address book". Sites will simply have to link to resources by full onion domain.

    I can only recommend a proper pet name system (who knows how hard it is to securely implement that on top of any modern browser). Or namecoin only because it's less bad than DNS and lots of people would use it for free DNS and NAT bypass with short route hidden sites.

    >pet name system anything less than most usable
    I have no idea why people still believe this but it's not in my interest to argue with them.

    >Idea 3) Embed onion addresses in SSL certificates
    >Idea 4) Embed onion addresses in DNS/DNSSEC records
    ISHYGYGYGYGHGGGTDT

    >web of trust based name sharing
    ISHYGGYDGYGGYDGTTGDDGYTDGYT
    see http://longpoke.github.io/f37c5de221cb361db07f046b31047f329ddb2ca2fe3ab…

    April 19, 2017

    Permalink

    The problem with human-meaningful names is that they are not global and cannot be so.

    So that leaves local authorities, curators if you will, who are entrusted with the task of keeping the names for things. Maybe this means curating a local version of the names that provide meaningful services to the community; maybe this means curating a local version of the names of people in a community.

    In the last century, telephone companies would maintain these sorts of locally-meaningful records, although we have seen clearly that aggregation leads to a wide range of problems, most prominently namespace collision and "gold rush" contention.

    Perhaps this sort of task is best left to the non-commercial authority of local librarians granted authority by localised power centres, such as towns, small businesses, divisions of larger businesses, or religious organisations. These people would be entrusted to maintain names on behalf of, say, tens of thousands of people. They would not need to achieve global consensus and they would be discouraged from doing so. They would aim to act in the best, local interest of the people they represent.

    April 25, 2017

    Permalink

    What about a system where:
    1. a user types: pipeleaks.onion
    2. TorBrowser detect that this is an invalid address, so
    3. TorBrowser somehow looks up all/published hidden services, and presents them to the user in a webpage like interface, like:

    Choose which Onion Service would you like to visit:
    pipeleaksbm49bjd8cht0dvhdh28bk39iyrebhejf.onion [Verified by TorHQ and GoodGuys]
    pipeleaksk20fxhb04hcvojhe0niwhgu9bnxoiehj.onion [Verified by SomeoneElse]
    pipeleaksndivje9j40hgkx09euv0439bkldm39gs.onion [Unverified]

    4. The user tries to recognise the good address, which is much easier than remembering the full address.

    Who is GoodGuys and how do I have a secure channel to them? Even if I knew what pipeleaks is and trust GoodGuys to properly authenticate domain names (whatever that means), how do I know they have the same "pipeleaks" in mind as me? This is the same problem I commented above which affects the PGP Web of Trust. This isn't even an Impractical (TM) issue, once you step out of the big 10 or so domain names of the west (google, facebook, microsoft etc). Even in every day conversation with competent people, I run into people who have never heard of Hacker News (the ycombinator one), and think I'm talking of The Hacker News, which has a large intersection of stories, and both are basically the same format: news sites with user comments - and both appear as the first or second hit for "Hacker News" on popular search engines such as Google and Bing. If they both had hackernews*.onion, we could go on for months before realizing we are even talking about different things. In cases where security is required beyond the likes of the phony stuff which protects your bank account, this scheme would utterly fail.

    GoodGuys, BadGuys, etc. would be just self-anointed hidden service directores, themselves also being hidden (or maybe clearnet) services. They would't authenticate anything, they would just help you identify the good .onion yourself. Or misguide you. Some of them could be “official” or you could add a list of other directories you got from some other source.

    They would get a request
    { gimmeAllOnionDomainsStartingWith: 'hackernews' }
    and they would return
    [{ domain:      'hackernews123blabla.onion',
       description: 'the ycombinator one',
       known: 'since 2013',
    }, … ]

    TorBrowser would gather these and display it to the user, and it would be the dear user's responsibility to choose the proper one.

    Also, TorBrowser could generate some colours and an image from the .onion address, like those avatar generators that make unique unicorn images from your user id to help choose/mess up things even more. :)

    > description: 'the ycombinator one',

    1. This wouldn't help in most cases because normal people don't care who is behind a service or product or other establishment. Apart from a small community around the San Fransisco startup scene, nobody knows or cares what ycombinator is, even if they know what Hacker News is. If they see hackernews (the ycombinator one) and hackernews (the joe shmoe one), it effectively looks like this to them: hackernews (a4h1byk91n) and hackernews (ma95hb1g5hg6) - indistinguishable aside from the gibberish. Even if they had title attributes set to Hacker News and The Hacker News, that would still be largely meaningless.

    2. At the time of creating the Hacker News domain, they likely wouldn't even have thought to put this additional context of "the ycombinator one", since they didn't know of The Hacker News at the time. Of course maybe there would be a company field, in which case they would probably put ycombinator without a second thought.

    The problems of this happening by accident aren't even a big issue. The problem is when an adversary forces this situation. Back the first time I installed Linux, I wanted to cryptographically verify that I download the right files, but I didn't even know who is behind the distro I was downloading. The download page could have designated any PGP key with any person's name, and I would have no way to tell if this is even the same name as what most people believe to be the real name. So of course Jon Doe could replace the page (by MITM or similar) and put his own keys (which are verified, because he is indeed the real Jon Doe). Do you know who is behind Fedora? Most people don't. Now even that issue aside, if it was common knowledge throughout the world of who is behind Fedora - let's say his name is Chris James, and he signs the files himself instead of some other developer doing it - I would still have no way to verify I have the real Chris James, as discussed in the link about the OpenPGP Web of Trust I posted above.

    April 27, 2017

    Permalink

    So if an onion service can have a name, the only way to prevent collisions is for all names to be known. Or is there some cryptographic magic that can test for a collision without knowing the names? Could the dining cryptographers problem or zero-knowledge proof offer us any insight?

    I think that if many onion services had given names rather than randomly-generated addresses, that would lend itself to name guessing. Onion services hoping to remain secret (after we figure out how to better ensure that) should not have a name!

    Which term is better: name, alias, domain name, onion name or something else?

    Should the system have a limit to the number of names an onion address may have?