# Are hash functions “intentionally” designed to be efficient?

I am curious to know if the hash functions are intentionally designed to be fast, or it happens to be like this. This is very interesting to know because on the one hand, efficiency is not considered as a property to design a hash function. On the other hand, if they are not efficient, a lot of applications and protocols will be affected, e.g., the hash chain.

• Of course, a hash function shall be as fast as possible. Where did you get the information that efficiency is not considered? – user27950 Nov 16 '16 at 14:05
• Well, if you look at the properties of a hash function, you only see (i) preimage resistance, (ii) collison resitance, and (iii) second preimage resistance. I have not seen efficiency as a strict requirement in designing a hash function. – Mohammad Khodaei Nov 16 '16 at 14:30
• For example, I see here that hash functions should be efficient: tutorialspoint.com/cryptography/cryptography_hash_functions.htm So, if this is a requirement, why they should be efficient? What is the reason behind that? – Mohammad Khodaei Nov 16 '16 at 14:33
• Well, if they are not efficient, a lot of applications and protocols will be affected, e.g., the hash chain. – poncho Nov 16 '16 at 15:38
• True. But many protocols were proposed exactly because of the efficiency property of the hash functions. It is not the other way around, i.e., hash functions were not intentionally designed so some protocols could benefit from that. – Mohammad Khodaei Nov 16 '16 at 15:51

It seems your question is about design / choice criteria for hash functions, so let's go through all of them (or at least the more important ones).

• Basic security. If your hash function fails to provide the basic security guarantees, e.g. 2nd and first pre-image resistance and collision resistance, there's no chance it's ever going to be used.
• Advanced security. This is also a "must-have" for hash functions these days and includes things like "acts like a PRF" or "can be modeled by a random oracle".
• Speed. If I have the choice between two hash functions that are equally secure for my purposes, I'm always gonna pick the faster one, unless there are other good reasons to pick another one.
• Endorsements. As everywhere, if you have a good "marketing department" your product is gonna be widely used. This also holds true for hash functions which benefit massively from endorsements such as "SHA-3 finalist", "SHA-3" or endorsement by NIST, BSI, ...
• Elegance. Many good hash function designs try to be simple but effective to ease analysis and give confidence that no "hidden problems" can be found because it's all "so simple".

To go a bit further into the speed side, you want your hash function to have a nice synergy with your hardware. E.g. Keccak has been designed to be fast once the gates for the the $\chi$ step will be integrated in the hardware (this is why hash competition have VHDL design requirement).

• Thanks for your response. What's is interesting to know is the trade off between all of these criteria, e.g., designing a more secure hash function (*-resistance) is more important, or a more efficient one (of course without degrading its resiliency too much). – Mohammad Khodaei Nov 16 '16 at 17:11
• These are no sliders, which have a clear trade-off and can be analyzed independent of everything else. Security more often comes as a hard lower bound - with zero room for discussion. I suggest studying the AES competition, there were others considered to be more secure but less efficient - maybe that's what you're looking for. – tylo Nov 16 '16 at 17:31

It varies. Some are designed to be fast and some slow. A slow hash is designed that way to make it hard to brute force attack it, such as for password storage. That means an attacker could try far fewer possibilities per second than with a fast hash.

For many applications, they want a fast hash.

http://openwall.info/wiki/john/essays/fast-and-slow-hashes

"Some examples of these slow hashes are bcrypt, PBKDF2 and scrypt. "