The string isn’t random. It’s a public key with the private key of the service able to decrypt content sent to it.

Anyone can generate a key with a vanity prefix, it just takes computing power and the longer the match, the greater the computing power involved.

Facebook's hidden service address is particularly impressive: https://facebookcorewwwi.onion/

It seems like everything except the 'i' is a prefix, a lot of computing must have went in to generating it.

One tool to do it is called 'Shallot' https://github.com/katmagic/Shallot

The readme includes a table of estimated computing time required. A 15 char prefix like Facebook's is not even on the table, and a 14 char prefix is estimated to take 2.6 million years. There is also a GPU version which should be an order of magnitude faster: https://github.com/lachesis/scallion/blob/gpg/README.md

Also, technically. the onion addresses not public keys, but derived from a public key. It's actually a hash of the public key.

It appears that the hashing algorithm used is SHA1. Source: The last few lines of the easygen function https://github.com/katmagic/Shallot/blob/master/src/math.c

Facebook said they just looked for Facebook and got very lucky. corewww does not have a lot of meaning.

We tried the same thing for PinkApp and got all sorts of much-longer matches that we could retcon into meaning something.

Facebook probably looked for anything matching "facebook(web-related words)", and were lucky to find one with only one errant character. There were probably enough acceptable variants that the effective computing time was less than 14 characters, maybe less than 13.

FWIW I've struggled to get keys generated by Shallot to persist very long but haven't found the cause. We've had to fallback to a non-vanity address. If anybody knows what I'm doing wrong please let me know!

What do you mean by "struggled to get keys to persist"?

It shouldn't make any difference how the keys were generated.

I mean on the network. It stops resolving after a few hours.

I don't think the way you've generated the key is likely to be the source of the problem, although I don't have any good ideas about what the problem might be, beyond the obvious (is the server still online? is for still running? is it still using the correct config?)

This is properly solved by the switch to stronger encryption, the new v3 onion addresses protocol (available with Tor 0.3.2.x-alpha) replaces SHA1/DH/RSA1024 with SHA3/ed25519/curve25519. Onion addresses are now 56 characters long, example: http://ffqggapqevcmylx6vtk5357i7bfjwbb6qchds3hlohangshxrwvdd...

Also something you may be interested in: OnionNS https://www.freehaven.net/anonbib/cache/onion-ns-pets2017.pd...

That does not solve anything. It just means the addresses are so long you are guaranteed no one is eyeball-comparing them. This makes phishing easier.

Did you look into the OnionNS paper?

As explained in other comments, onion addresses are keys. However what you'd taking about does exist on zeronet, where people can buy .biz domains.

uh, out of curiosoty, how do they handle conflicts with already stablished domains on that tld?

.bit not .biz

To my understanding, there is no way to handle conflicts. If another person gets your private key, then they can collide their domain name with your domain name (and, speculatively, probably split traffic?)

It's not a real TLD.

It's a real TLD, see [1] and [2]. It's just not controlled by a central registrar like a traditional TLD.

[1]: https://tools.ietf.org/html/rfc7686

[2]: http://www.ietf.org/mail-archive/web/ietf-announce/current/m...

.bit is not an ICAAN or IETF recognized TLD, which is what djsumdog was speaking about

The original comment said .biz when they may have ment .bit