Hashing is also not secure hashing, cryptographic hash functions are a small subset of all hash functions. I wish the author would make that clear. I've seen many abuses of cryptographic hash functions where ordinary (though perhaps specialized) hash functions would be more suitable.
Yes, but! Many libraries have migrated to cryptographic hash functions even for non-cryptographic use cases such as hash tables. They choose a random key. This mitigates problems where the algorithm performs much worse on pathologically bad, perhaps adversarially chosen, data sets.
A library should absolutely not be using a cryptographic hash for something like a hash table unless they have very particular requirements. You don't want to force a significant performance penalty on all your users when there are good general-purpose hashes like XXH3 out there.
Also, in general I disagree. For most people, safe defaults like hash tables with safe hashes and CSPRNG for random numbers are fast enough. And they have the important property of keeping people from shootings themselves in the feet.
People who have more stringent perf requirements will know and shouldn’t have a problem choosing a different implementation.
If you are worried about adversarial data, it's probably better to choose a more suitable data structure instead (or change the way you deal with hash collisions: linear probing is probably not a good idea if the data is sketchy). Hash tables are only performant if the hash function is fast, and cryptographic hash functions are anything but.
Checksums might be a better example. People often use cryptographic hashes for check summing in non-security related scenarios. And, depends on the implementation, but MD5 or SHA-1 is often the same or better performance than a CRC checksum. That shouldn't be the case, but it often is.
If duplicate hashes would cause an issue, you might as well just use a cryptographic hash function. For a non-specialist it's quite hard to evaluate the space of non-cryptographic hash functions. There's so much more documentation and information available for cryptographic hashes compared to everything else.
And you need to be sure that the properties you're trading off are really something you don't need. Using a cryptographic hash is much simpler, has fewer ways to going wrong and usually isn't that slow anyway.
To your first point: it’s not a bulletproof arrangement, either. PbKDF-hmac-sha1 can produce duplicate hashes if the input is larger than the hash block size. The special case is: if the input is bigger than block size, do one round of sha-1 before proceeding.
I agree with your second point, developers reach for asymmetric signatures when hmac would do, and reach for hmac when a long fast non-cryptographic algorithm would do. I _think_ its an over-abundance of caution rather than a misunderstanding of the characteristics of hash functions.
PbKDF-hmac-sha1 isn't a Cryptographic Hash Function. It's a Password Hashing Function. They have different security properties, and must not be confused. Sadly they're confusingly named.
Yeah, and it’s not pedantic. I hope a blog post nowadays points newcomers to an example decision tree for use-cases. Though we should hold this blog post to its own standards; it’s not intended to be best-practices.
And to work with the analogy of the article: grinding a cow into a hamburger is hashing but not secure hashing, because if you have the right tools you can inspect the hamburger and determine some properties about the particular cow that it came from, like if it had mad cow disease. I dunno exactly what a securely hashed burger would be, but I don’t think it’d taste very good.
You'd turn the beef into totally unrecognizable meat paste that could come from any number of species. Pulverize the meat, wash it with solvents, and cook until there is nothing left of the original protein structures or flavor (i.e charcoal). Just unique enough in physical composition to say this lump of burnt paste is different from that lump of burnt paste but not enough information to say anything else about it or what it originally may have been.
