Yeah I can't understand why everyone wants "fast" so badly. Something which deliberately can't be made fast is the way to ensure security. I don't really care if my SSL negotiation takes an extra 1ms or if my purchases on Amazon cost an extra $0.001 each because of the expense of the hash functions. I'd like security, thanks. When the price is so trivial, who really cares if it's 10x as expensive?
Because there are a lot of ways to make a fast thing slow in cases where "slow" improves security. And at the same thing you're not hurting performance in cases where a slow function doesn't significantly help security and performance might be important.
Making your hash function twice as slow means you've halved the number of hash operations you can perform with fixed computational power. On the other hand, in many situations the resultant doubling of your security margin makes absolutely no practical difference since the existing margin is many, many order of magnitude away from any attacker's capabilities. Making things twice as hard on an attacker sounds impressive, until you think of it like asking someone to travel 2 billion light years instead of only 1 billion. Both are ridiculously outside of our current capabilities, but anyone able to travel 1 billion light years is likely going to be able to travel 2 billion as well.
In more specific terms, making a function with 256 bit security 10x slower has a pretty dramatic impact on performance with a resulting security increase to about 259 bits of security. You have a fairly marginal security increase for making your function 10 times slower. Modern cryptography is fast, but it's not yet fast enough that running at 1/10th the speed won't be noticeable in many situations.
Would a simpler way to put it be that if you make something fast and do it lots of times, it's difficult to speed up. If you make something slow and it's done significantly less times, there's the risk that someone will make it a lot faster?
Yeah, reminds me of the CPU clock speed wars. [0] Shouldn't crypto security margin be $-oriented [1] related to the secrets / lives / etc. being protected? In backup / availability formally use something called a BIA to justify investments based on risk to operations. (A document used by IT people &| consultants to get business people to spend $ on backing up critical shit) [2]
There are applications that need to hash data as fast as possible as long as there's a perception of a reasonable security margin. ZFS uses SHA(2)-256 for data checksumming. Some crypto protocols involve HMAC as well as encryption for transmitted data. If a hash can't keep up with line rate on SAS, FC, or many-GigE links, because you wanted maximum security, those users are going to find another, faster, less examined, hash function.
The criteria for SHA-3 is not "as secure as possible". An application that needs as secure a hash as possible should use a protocol that combines multiple hashes of different families.
If "fast" did not matter, we could use generic constructions of most cryptographic primitives and have very strong security claims e.g. "If you can find collisions for this hash function, you can solve the discrete logarithm problem on elliptic curves." There are a few downsides to such an approach but the primary one, the one that kills it in practice, is speed.
