[cliveowen]

It's not just about compromised encryption algorithms, it's also about picking the right algorithm for a given purpose.

For instance, an hashing algorithm can be used to securely store passwords, and must therefore be slow, or to find duplicate files, a task which greatly benefits from speed. If you use a fast hashing algorithm to "securely" store passwords you might as well use a compromised algorithm since the security is nonexistent in both cases.

I think the same applies to crypto algorithms: it doesn't matter if the building blocks are individually secure if you don't know how to put them together in a secure fashion.

[tptacek]

You might save yourself trouble by thinking of a "hash algorithm" as an infrequently-used primitive, a password hash (or KDF) as something you'd store a password authenticator with.

[StavrosK]

Nobody is arguing against that. The OP is asking about compromised algorithms. Sure, non-compromised algorithms can still be used incorrectly and be insecure, but compromised ones won't be secure no matter how they're used.

Also, you don't use hashes to store passwords, you use KDFs.

[p4bl0]

> Also, you don't use hashes to store passwords, you use KDFs.

Well, technically a hash can be seen as a particular key derivation function (KDF). Not a proper one for the purpose of storing passwords I agree, but then most KDFs are built using salt + an iteration of hash functions, to my knowledge at least (which I admit is not very deep on the subject).

[tptacek]

A hash serves as the PRF in a KDF construction; it's a building block, not a subset.