3 ms·
No -- You are confusing password hashing algorithms with general purpose hashing algorithms. Algorithms like bcrypt and scrypt have a tunable difficulty paramet
by ori_b 11y ago
No -- You are confusing password hashing algorithms with general purpose hashing algorithms. Algorithms like bcrypt and scrypt have a tunable difficulty parameter, and are designed to be slow.
For general purpose hashing, you want to check if the fingerprint of these ten gigabytes of data is the same as the fingerprint of these other ten gigabytes, as quickly as possible. Or whether a file that you downloaded is the same as this other file. Or whether the data that you transferred has been tampered with or corrupted. Speed is important enough that this was one of the criteria in the hash algorithm selection process.
The key feature of a general purpose hashing algorithm is resistance to preimage attacks. In other words, "If I want hash 0x123456, what should the input be?" needs to be a difficult question to answer.
Speed is key when you are getting a fingerprint of a large amount of data. Don't use a general purpose hash directly for hashing passwords: It's better than plain text, but it's inferior by a long shot to special purpose password hashes.
- laumars 11y agoI'm not getting confused. SHA-3 can be used for cryptographic hashing. In the linked PDF: "The SHA-3 family consists of four cryptographic hash functions, called SHA3-224, SHA3-256, SHA3-384, and SHA3-512, and two extendable-output functions (XOFs), called SHAKE128 and SHAKE256." If BLAKE isn't intended for cryptography then it's not a direct competitor to SHA-3.
- ori_b 11y agoGeneral cryptography -- for example, message validation -- does not need to be slow. In fact, slow message validation would cripple hash functions for cryptography, increasing CPU load and reducing throughput. Password checking is an edge case. Special purpose password hashing functions with tunable difficulty should be used for those. Do not use general purpose hash functions: They are better than plain text, but they are designed to be fast, and this makes it easier to brute force them.
- laumars 11y ago> General cryptography -- for example, message validation -- does not need to be slow. In fact, slow message validation would cripple hash functions for cryptography, increasing CPU load and reducing throughput. There is definitely a trade off between the two (performance on servers vs rate of passwords an attacker can crack). But generally the advice is to go for the slowest you can afford. Hence why KDF's have an iteration parameter so passwords can be hardened as harder gets faster.
- ori_b 11y agoNo: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another. Trying to make one that does both leads to something that sucks at both.
- laumars 11y ago> No: This is why you have a split between KDFs and hashes. Where you use one, you would not want to use another. That's not true either. Hashes are recommended to be used as input to KDFs. "Modern password-based key derivation functions, such as PBKDF2 (specified in RFC 2898), use a cryptographic hash, such as SHA-2" Source: https://en.wikipedia.org/wiki/Key_derivation_function#Key_stretching https://en.wikipedia.org/wiki/Key_derivation_function#Key_st... > Trying to make one that does both leads to something that sucks at both. eh? Nobody is advocating that what-so-ever. Not me, not anybody. I think you're now arguing with me for the sake of arguing with me. :-/
- ori_b 11y agoOk, that was sloppy phrasing on my part, but my point still stands: The entire reason that KDFs exist is to deal with the fact that hash functions are designed to be as fast as possible. If it made sense to make hash functions slow, then KDFs would not be needed. While KDFs do use hash functions internally, the hash function is an implementation detail.