Hacker News Reader

Comment by dokument | Hacker News Reader

I understand not wanting to use SHA-1 now for security reasons, but is it still an OK practice to use it as a general hashing function for a uuid/data checksum?

View on HN

> is it still an OK practice to use it as a general hashing function for a uuid/data checksum?

No. If you don't care about collision resistance, use MD5. It's faster, it's smaller, and it makes it obvious to everyone than your software isn't supposed to rely on collision resistance.

No. MD5 is a cryptographic hash function. For the purposes stated one uses a non-cryptographic hash function, such as seahash. The difference is the latter is much faster but does not provide protection against an intentional collision.

1: MD5 still provides preimage resistance (both first and second), which is sometimes useful.

2, and my real objection:

  $ md5sum /dev/null
  d41d8cd98f00b204e9800998ecf8427e  /dev/null
  $ seahashsum /dev/null
  <stdin>:2:0: seahashsum: command not found

That said, my main point was don't use SHA-1, because if you actually need a half-broken hash function for something, MD5 has all the same properties (good and bad) for cheaper.

The real question is why you would want to. You have a lot of other options! For example, on 576 byte messages on a core i7, eBASH reports the following performance characteristics:

- Blake2b (~20% faster)

- SHA-384/192 and SHA-512/256 (~50% slower)

- SHA-256 (~100% slower)

- SHA3-224 and SHA3-256 (~150% slower)

So if speed is absolutely important to you, like you are hashing millions of messages a minute and you have profiled and the speed of the hash function is absolutely the most important thing, then link the Blake2 or more recently Blake3 libraries and get the extra speed AND you don't have to deal with all of the security vulnerabilities.

Or, if speed is modestly important to you but you need to use primitives that are available on every single computer you will ever encounter, use SHA-512 and then truncate it to 32 bytes. Or if you really need that 160-bit level truncate to 20 bytes. (Truncation is usually a good thing with hash functions, defending against something called length-extension attacks.)

Or if you want to be substantially safer than all of these options and you are not doing a lot of hashing, use SHA-3. Also the performance of the others (that are not BLAKE) is generally somewhat artificially enhanced by dedicated processor instructions which will almost surely also happen for BLAKE (as it is based on the ChaCha cipher which is reasonably well used) and SHA-3 (as it is the new US government standard). I can't off the top of my head speak to the CoffeeLake Core i7 architecture without digging up some research about what instructions it implements, but its SHA-1 is 25% faster than its MD5 which suggests some dedicated SHA-1 instructions, at least.

Are you protecting against random accidental data corruption? Or malicious attackers?

Everyone is protecting against accidental data corruption, until someone figures out how to turn it into an attack.

Even when you ask people "is there any universe in which this could be used as an attack?" most people will reflexively say "no, of course not."

Most of us are wrong, which is why you have professional pen testers.

Reply on news.ycombinator.com