The name of .onion address is the hash of a public key, so you can't choose it, or rather the only way is to generate random public and private key pairs and to keep the one that interest you.

Facebook must have generated an awful lot of key pairs to get "facebookcorewwwi". By the way, I hope they deleted the other generated pairs…

I have good faith that they didn't, or certainly not all of them. When Alex described the entire process they went through, he also smirked that should that primary key ever get compromised they have several others, almost as good, ready as drop-in replacements.

I do think he also mentioned that they only cared about keys that had their required prefix; all others were destroyed without anyone ever having access to them.

> I do think he also mentioned that they only cared about keys that had their required prefix; all others were destroyed without anyone ever having access to them.

Okay, that is what I was implying would be terrible otherwise. But actually it is quite obvious that they would not spend the disk space necessary the keep every single generated key pairs now that I think about it.

How would that be terrible?

The number of generated key pair to find "facebook" + keywords must have been gigantic, maybe even so much that it could be used as a kind of rainbow table which would allow people (or three letters agencies) who can access it to attack hidden services that use one of the .onion for which a corresponding private key is known.

Relative to the 2^80 (1,208,925,819,614,629,174,706,176) possible onion addresses, whatever they generated would be miniscule.

Indeed. I was being stupid and didn't take the time to really think it through. Thanks to you and all the others who pointed that out :).

Presumably those 3 letter agencies also have the technology to generate RSA keys.

Nope. They ran a cluster to generate billions of addresses, and used some logic to find a nice one. But that won't help them a bit to find a specific address, since all the addresses they generated are only a vanishingly small fraction of the possible addresses.

This was a huge discussion on the Tor blog or subreddit. It was concluded that it is unlikely that they even found one existing key.

If that is indeed tractable for a side project at Facebook over a few weeks, it's definitely tractable for someone who actually cares to attack Tor.

If I understand correctly finding an "equally good" domain name starting with facebook<something> should be equally possible yes.

Finding that same one again? Not likely.

This is not vulnerable to brute-force nor rainbow tables.

That shouldn't matter. If the scheme is vulnerable when some company generates a bunch of keys, it is vulnerable whether those keys are deleted or not.

If the key hash did not have facebook as the first eight characters it did not even get passed up to the aggregator and was instantly discarded.

The onion-name is a hash of the public key the service uses, so you can't just pick a name and use it. They had to try many keypairs to find some that hashed to "facebook...." (Normally you generate your key and just use whatever name that hashes to, but it's cool to have one that's easy to remember)

Onion names are sort of public keys. You generate a secret key, then that's transformed/hashed into the public key that is your onion address.

Since onion addresses are essentially random strings of a certain length, the only way to get a "vanity" onion address is to brute force it.

The third part on the Tor project's blog at https://blog.torproject.org/blog/facebook-hidden-services-an... describes this well.

Check out mapgrep's comment on another thread below for a more in depth answer, too.

Also, if I'm not mistaken, this means that if YOU can brute force a vanity domain, anyone else willing to throw down the same amount of computing power can perform the same brute force and discover your private key, taking over your onion site?

Edit: probably wrong, see below

It requires substantially more compute power to match "facebookcorewwwi" vs just finding a hash with a prefix of "facebook" that looks readable. Good luck hashing the remaining eight characters!

Well, it would just take twice as long as hashing the first 8... /s

I realize that was sarcasm.

But for the non-hash-aware among us, it would take on average 2,147,483,647 as long to brute force the last 8 with the same computing power and 4,294,967,295 as long to hash every combination of the last 8. This all assumes no vulnerabilities in the algorithm, of course.

It's base32, not base16, so you're off by several orders of magnitude - numbers should be 549,755,813,888 and 1,099,511,627,776.

I believe you are correct. I appreciate the correction.

Normally you brute force vanity addresses by having a range of acceptable outcomes, whereas to brute force a specific vanity address* you are only targetting a single outcome.

So they might have just set it to filter for facebook[dictionaryword]+ and this was the best match.

* Actually any address, it's not limited to brute forcing vanity addresses.

I guess I incorrectly assumed the process would be repeatable, but now I see that getting a specific duplicate equals bruteforcing the entire key space - even if the prefix is a chosen vanity name. I confused it with the effort of getting a similar address where just the vanity prefix needs to match.

Sure. The same is true for anything that uses public key encryption (Bitcoin for one). But the amount of computing power needed doesn't exist.

According to this person's math [1]: "It would take ~6.7e40 times longer than the age of the universe to exhaust half of the keyspace of a AES-256 key"

I don't know if Tor uses AES-256, but I'm sure any reasonable encryption algorithm would be similar.

[1] https://www.reddit.com/r/theydidthemath/comments/1x50xl/time...

.onion addresses are just 80 bits, not 256. Someone estimated[1] that the amount of work to brute force one address is approximately the same as the amount of hashing that has been computed by the bitcoin network up to now, so it's clearly not physically impossible. This weakness is apparently a practical problem, because it made people unwilling to automatically issue SSL certificates for .onion addresses [2].

[1] https://news.ycombinator.com/item?id=11388997 [2] https://blog.cloudflare.com/the-trouble-with-tor/

The energy calculation assumes the computation is irreversible. If you use reversible computing, there is no lower bound: you can compute as much as you want for as little energy as you want.

The time calculation assumes our current computers and disregards Moore's law.

You have to create the algorithm to reverse an arbitrary AES-256 key, which is considered to be impossible, so that doesn't really make a difference. Your comment about current computers fails to grasp the scale that we are talking about here:

> It would take 10^38 Tianhe-2 Supercomputers running for the entirety of the existence of everything to exhaust half of the keyspace of a AES-256 key.

Let's assume that Moore's law is true for forever. In 300 years we will have a super computer capable of cracking a single AES-256 key in 37 millennium. However claiming that Moore's law will stay the same for 300 years when many think it won't last 30 is foolhardy.

>You have to create the algorithm to reverse an arbitrary AES-256 key, which is considered to be impossible, so that doesn't really make a difference.

What? Why is brute force impossible to code? I don't understand what you're claiming.

I agree that adding in Moore's law doesn't change the numbers by much. Moore's law plus weakening of cryptographic assumptions might do it, though. Plenty of previously-believed-to-be-strong crypto algorithms have been cracked, it's reasonable to think that we just don't have the tools to create unbreakable codes yet. (E.g. RSA is known to be breakable with quantum computers with Shor's algorithm.)

> What? Why is brute force impossible to code? I don't understand what you're claiming.

You claim that a reversible algorithm takes zero time. I said that requires a reversible algorithm that applies to an arbitrary AES-256 key which is currently thought to be impossible.

Brute forcing is not breaking but instead simply enumerating the key space and is subject to the slow downs we are talking about here.

> I agree that adding in Moore's law doesn't change the numbers by much. Moore's law plus weakening of cryptographic assumptions might do it, though. Plenty of previously-believed-to-be-strong crypto algorithms have been cracked, it's reasonable to think that we just don't have the tools to create unbreakable codes yet. (E.g. RSA is known to be breakable with quantum computers with Shor's algorithm.)

But you are missing the point of cryptographic systems, the goal typically isn't to be forever uncrackable, it is to be effectively forever uncrackable which includes upgrading the strength of your cryptography over time.

If we were talking about cracking crypto within 100 years then maybe we could talk about reasonable fear, but all of these things involve timelines that are longer than that (including quantum computer work).

>You claim that a reversible algorithm takes zero time.

No, you misread my comment. Reversible computing can take almost no energy.

Shores algorithm doesn't break anything. It just reduces the key space. Considering the major increase in energy costs and major lag in computational power of quantum computing, shores algorithm won't be a threat to today's crypto for hundreds of years to come.

It reduces key space for most symmetric algorithms, but completely breaks RSA and ECC making them run in polynomial time.

Onion domains are just an encoding of a hash of a public key. To get a memorable name, you have to find a keypair that hashes to some letters you want. There is no correlation between any of the characters, so you have to do an exhaustive search to find nice strings.

Because it happened in the past with a hashing algorithm that isn't resistant to getting faster as time progresses.