isn't slow better in this case? I mean if it's fast to generate, it's fast to crack, right?

 > isn't slow better in this case?No, guy's looking for a hash table hash, not a cryptographic one. For a hash table you're looking for low collisions and high throughput (so your hash table is fast) first and foremost.
 Even for cryptographic hashes, fast is what you want most of the time. Look at it this way: when you connect to a web site via SSL, all the data you send will be hashed for authentication. Do you really want this to be slow?
 Cryptographic hashes should be as fast as possible while not sacrificing collision resistance. Hashtable hashes should be as collision resistant as possible while not sacrificing speed.Sort of anyway.
 For cryptographic purposes you usually want fast digests and slow key derivation functions.
 The person specifically requested an algorithm for a hash table. Nobody is going to attempt to crack that
 nobody? This exact problem was a massive issue within the year.
 Using a slower hash would make the issue worse (linearly): the collisions would still be there, but now each insertion would take even more time due to the extra computational cost of the hash.
 [deleted]
 EDIT: parent basically said "use a cryptographic hash".You need some kind of random salt, too - it's not that hard to find a decent number of near-collisions even in cryptographic hashes. (E.g. if your hash table doubles in size whenever two keys end up in the same bucket, an attacker needs to spend O(2^n) operations to find two keys that agree in the first n bits, which will make you do O(2^n) operations and use O(2^n) memory.)
 > No, using a slower cryptographic hash would produce better distributionThat absolutely isn't an intrinsic property of cryptographic hashes.
 Using a faster cryptographic hash would be better.
 Not if you're not looking for it to be hard to crack. Suppose you're generating quick checksums, using a hashtable, indexing non-malicious data, etc. In those cases you want a very fast hash function, and you're not worried about folks being able to find collisions for existing hashes, or create multiple values with the same hash.
 There are times you want something that won't be a cracking attack. E.g. to randomly (but consistantly) partition data (i.e. a hash table).
 Given Moore's law and the prevalence of botnets and cloud computing - hash speed really isn't a very strong means of defence against cracking...
 Uh? Hash speed is pretty much the only means of defense against brute-force cracking (assuming the hash function isn't broken and the attacker has no other vector available).(low) hash speed is the whole point of PBKDF2, bcrypt or scrypt.
 Can we stop calling them hashes? They're key derivation functions. I know it's a long, awkward term, but a lot of people in this thread are confusing the technical requirements for cryptographic hashes and KDFs, so I think that being precise about this is warranted.
 But talking about salt in our hash sounds delicious.Talking about stretching our hash, though, sounds like some strange tasting taffy...
 You'll find that adding a long salt, unique to each password, is a far more effective protector against brute force than "hash speed".to learn more about preventing brute-force attacks