mouss wrote: > John Hardin a écrit : > > Just out of curiosity, why? An MD5 hash is shorter than an SHA hash (an > > important consideration when you're making lots of DNS queries of the > > hash), MD5 is computationally lighter than SHA, and MD5 is robust enough > > for this purpose, even though artificial collision scenarios exist. > > because it's good to abandon weak algorithms, once for all. the small > wanna be performance benefit that you might find is useless.
But the logical conclusion of that argument is that all hashes are insecure and none should ever be used. Because even though SHA is considered secure today the expected trend is that it will also fall to attacks in the future and be replaced by something heavier. > we keep seeing people using weak stuff because "it's enough" and "it's > faster/lighter/..." with the results that you know. And there is a reason for that. Right-sizing is also important. It isn't good to use a large construction bulldozer when a single shovel is all that is needed. If MD5 is the optimal size then it is the right size to use regardless of vulnerabilities when used in a security critical role. > if you're worried about performace, don't hash at all. would you use a > cesar/base64/... ? either you need security and you use an algorithm > that's not considered broken, or you don't. You have hit the problem exactly. If we follow the line of logic you have presented then we can never hash. Because there isn't ever going to be a hash that doesn't ever have collisions. > > Granted I wouldn't sign a legal document with it any more, but for a > > private perfect hash of an email address, why not? > > it's weak. don't use it anymore. we have many "secure" alternatives, why > go for "bugward compatibility"? Until SHA falls too. Bob
