Hacker News Reader

Comment by bflesch | Hacker News Reader

I'm not a tor expert, but could this be solved by using something like namecoin for DNS within tor? So there would be a "proper" domain system for the .onion routes?

The whole confusion comes from the fact that tor domains have this random string added to the name you actually want to take, right?

View on HN

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.

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?)

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

If Facebook can generate an address with only a single character being random (the trailing ‘i’), couldn’t an attacker generate anyone’s address by just applying 26 times more computing power?

Either Facebook didn’t target the trailing “corewww” or the .onion URL scheme is broken (since Facebook would be able to take over any .onion URL by just spending 26 times as much compute power as they did with https://facebookcorewwwi.onion/).

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.

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?

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

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?)

.bit not .biz

Reply on news.ycombinator.com