erm... i'm pretty sure that none of the hashing algorithms were designed to be slow. if someone came up with an algorithm that provided exactly the same security as SHA-1 but shaved an order of magnitude off the calculation time, that would be used instead. the security is in infeasibility of coming up with two different inputs that map to exactly the same digest. this is ruled by the size of the digest (the probability of a collision is 1 in 2^128 for an ideal 128 bit digest and 1 in 2^160 for an ideal 160 bit digest). those are both pretty much astronomically insignificant. the 160 bit key is of course inherently less likely to produce a collision but 128 is still pretty good. compared to those probabilities, actual execution time of the calculations are insignificant. since the computers doing the hashing legitimately might have to be doing a lot of them, you want them as efficient as you can (this also might to have to be done on things like smartcards and low-power portable devices where CPU speed isn't as abundant.

MD5's problem is that it's far enough from the ideal 1 in 2^128 that cryptographers (who are orders of magnitude more paranoid than civilians) get a little nervous.

anders pearson