Hacker News Reader

Comment by jgrahamc | Hacker News Reader

The most interesting part of this (to me) is that they brute-forced the .onion address (which is normally the SHA-1 hash of a public key).

Good thread on StackExchange about how to do that: http://security.stackexchange.com/questions/29772/how-do-you...

View on HN

Also commented downthread, but we got extremely lucky then went the backronym route as shawabawa3 guessed. (I'm an engineer at FB.)

That is extremely lucky. That's, what, 82 bits if you'd chosen the whole thing?

A more manageable 61 bits for 12 characters or so, from my recollection. Did you pile a dictionary attack on top of that?

I don't believe this does "break hidden services". That's just a truncated key fingerprint, not the key, and a collision would I suspect (but haven't checked) be a loudly visible error.

Roger Dingledine (Tor project, not FB) shared some accurate background here: https://lists.torproject.org/pipermail/tor-talk/2014-October...

>That's just a truncated key fingerprint, not the key, and a collision would I suspect (but haven't checked) be a loudly visible error.

Actually, a name collision would still mean hijacking the traffic, even if they don't have the same private key. The last HS to announce "owns" the name.

Tor still uses SHA1? I understand clueless download sites (such as FossHub) and projects still using MD5 and SHA1, but I would hope projects that are supposed to be about security would've stopped using SHA1 a long time ago. If they dread moving to SHA2 because of its much slower performance, they should at least use BLAKE2 [1].

Even NSA-influenced NIST recommended against using SHA1 after Dec. 2013. And when NIST recommends a deadline for change, you know you should be doing that at least 3-5 years earlier to be safe against state sponsored/NSA attacks.

[1] - https://blake2.net/

Agree. I never understood why onion names are so short; they're not even the full SHA-1 hash:

> The .onion name is computed as follows: first the SHA1 hash of the DER-encoded ASN.1 public key is calculated. Afterwards the first half of the hash is encoded to Base32 and the suffix ".onion" is added. Therefore .onion names can only contain the digits 2-7 and the letters a-z and are exactly 16 characters long.

(Source: https://trac.torproject.org/projects/tor/wiki/doc/HiddenServ...)

Then move to I2P where there are inanely long .b32.i2p hashes. I believe Tor stuck to sixteen to balance ease of use with security. I2P decided not to truncate their hashes since they already have memorable short.i2p entries in downloadable hosts files.

.onion addresses aren't particularly memorable anyway (Facebook's nonwithstanding). They wouldn't have to go to insane lengths like I2P does, but it seems like not cutting the SHA-1 in half would make it much stronger. I just feel like in striking a balance, they should err on the side of huge security margins. On the other hand, I don't really have an intuition for the strength of the current addresses, so it's not meant as criticism as much as a quest for understanding.

Although I agree it isn't cakewalk to memorise an onion URL, it is possible and many people do it usually by grouping or mnemonics. I'm not against any change/improvement to the current address generation system in Tor; there are certainly other better possibilities for both security and scalability.

Even using MD5 for .onion URL generation would be pretty safe. While MD5 is completely and utterly broken when it comes to collision resistance, there aren't any (public) preimage attacks that indicate that cracking it is feasible[0].

The move to slower hash functions is really only important when you're dealing with passwords because the input is enumerable enough to bruteforce to begin with. In general, having a fast cryptographic hash function is extremely desirable, and, for applications where the input is essentially random (nonces and randomly generated keys etc) it's fine.

[0] https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability

Reply on news.ycombinator.com