[16s]

Cryptographic hash functions must be efficient to compute. Those examples (scrypt, bcrypt, etc) were designed to be difficult to compute. Those are password hash functions, not cryptogrpahic hash functions. Two totally different things with different purposes.

[ReidZB]

Well, in complexity theory (which theoretical cryptography uses heavily), an efficiently computable function is one that has a polynomial-time algorithm to compute it.

I mean, wouldn't you say that scrypt is efficient to compute? For instance, is 5 seconds not a relatively quick function evaluation? Compare that to super-polynomial-time attacks, some of which wouldn't succeed before our Sun burned out and Earth died. And if you ramp up the security parameters to an insane degree, the user can no longer compute the function themselves. That's the reason for the "efficient to compute" clause in most definitions.

So, while you're right that the fact that KDFs are designed to be much slower than hashes is what really separates them, that doesn't disqualify KDFs from (technically) being cryptographic hash functions. At least, not if you view the definition in a theoretical sense, which is the appropriate way to do so. Still, I agree with your premise; in a practical sense, KDFs shouldn't feel like they are cryptographic hashes, since their purpose is markedly different.