You should not use md5 for anything. It's completely broken and that's just asking for trouble if someone swaps out whatever your checksums are checking. It's worth the security to swallow the extra computational power. Though, if you're hosting something no one cares about, it's still worth the security to keep your small audience safe from the random malicious person you thought you'd never see.

I'd much rather have it as a well known meme that "md5 is broken, don't use it. Period." than a list of caveats like "ok for non security" or "ok with hmac".

I've seen many claims from good engineers of the sort "this design is ok because it's not for security" when it absolutely was.

A simpler rule wins, even if it costs a bit now. It'll save someone in a bigger way later.

Good points.

I think the point they were making was that since we know of weaknesses in certain situations we should avoid using it even in the safe situations so that we can eventually drop it from crypto libraries all together. There are alternatives that we can all move to.

Let's say I make a hash of an asset and put it into a very long-time archive (like 100 years or whatever). What checksum algorithm should I use to be sure it will be readily available in software after 100 years? And to make the choice more realistic, let's assume that the algorithm must be sufficiently fast today (like md5 is).

The answer is that you don't want a hash, you want a solution that is ArchiSig or TR-ESOR (or something similar) compliant.

So what's the right algorithm to use instead of md5 if I just want a fast checksum that's widely supported?

BLAKE2b or BLAKE2bp should be a good choice for that. Or just CRC if you care only about unintentional changes.

SHA256

If SHA-2, do use SHA-512, since we are living in a 64 bit world.

SHA-512/256