MD5 is not broken for the usage that you think it's broken for. Please don't snipe on things like this again. People like you who say things like "md5 is always bad" or "you should bcrypt, duh" are literally cargo culting the idea of computer security.
In addition to the fundamental technical deficiency you've demonstrated, people who opine on security threads while not quite understanding anything about computer security allow charlatans to sell "computer security". Every single comment like this lends credence to literal scam artists.
¹note, this is actually a prize for a weaker claim than an preimage attack; all I want is a second preimage (!)
MD5 is known to be a poor option. And every few years the practicalities of attacking it increase. And when the type of attack described here does become practical, all we'll be hearing is one side saying "they had ten years to fix this" and another side saying "but experts we consulted said it was fine".
It is incredibly easy for whatever process builds a website with an MD5 hash of a download to instead display something else, so the cost trade off becomes:
Cost: Virtually nil Mitigation: Currently minimal but has future potential
That a company would look at that and say "I guess we'll make a choice to stick with MD5" says something, even if it doesn't say the website downloads are easily compromised.
Alternatively, the parent comment could be pointing out that no hash signature that only exists on the download site itself offers value, and they would be better served offering a GPG signature or similar.
In addition, you are completely wrong about the harm caused by simplifying the rules of thumb for security. There is not good reason to ever use MD5 for this purpose, and saying "MD5 is ok in some cases" has the potentially to do far more harm than "never use MD5".
> note, this is actually a prize for a weaker claim than an preimage attack; all I want is a second preimage (!)
Don't act like you are doing GP a favor, second preimage is the attack that would cause a vulnerability in this usage of MD5.
You are the one who is"opin[ing] on security threads while not quite understanding anything", so I think before the next time you condescendingly correct someone you should make sure you have a basic understanding of what you are talking about.
Aside: a preimage attack implies a second preimage attack.
Not all devs are security experts, or can even afford to focus on security. To deny the value of rules of thumb is to deny that they need to consider security.
> Did I ever say "MD5 is ok in some cases"?
Oh, really? Were you not arguing that MD5 is ok if you only need preimage resistance?
> MD5 is not broken for the usage that you think it's broken for. Please don't snipe on things like this again. People like you who say things like "md5 is always bad" or "you should bcrypt, duh" are literally cargo culting the idea of computer security.
Hmm. Seems like you were...
It's almost certainly a question of when, not if, I will be able to collect on that offer.
Correct; it's broken for everything since we've got the computational power to make it essentially ineffective.
MD5 is still preimage and second-preimage resistant.
Which means, the published MD5 on on the Intel site would have to be the hash that the attacker created.
Though I'm sure there are better methods that Intel could implement.