4 ms·

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 t

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/ https://blake2.net/

haakon 12y ago
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/HiddenServiceNames https://trac.torproject.org/projects/tor/wiki/doc/HiddenServ...)
- wowaname 12y ago
  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.
  - haakon 12y ago
    .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.
    - wowaname 12y ago
      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.
nly 12y ago
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 https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability

haakon 12y ago

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/HiddenServiceNames https://trac.torproject.org/projects/tor/wiki/doc/HiddenServ...)

wowaname 12y ago
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.
- haakon 12y ago
  .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.
  - wowaname 12y ago
    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.

nly 12y ago

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 https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability