Okay, so you are saying that there may be a design flaw we just haven't seen yet, based on historical precedent. Which is a very weak argument, because you are just making the case for the possibility that you may be correct, and you are just pointing to a historical precedent.

Can you prove that there is no hash function that is not vulnerable? If anything man-made is vulnerable, then there cannot any invulnerable system. That is what you need to prove to win the argument. And if we can prove that any system is unbreakable, you are wrong.

One frustration I have with these kinds of analyses on HN is that they're premised on an idea that cryptanalysis progress is unknowable, and that it's just a matter of time before whatever broke the last iteration of a design is going to break the next iteration of a design. As if cryptanalysis is so complex and forbidding that you might as well think of it as a geological-scale weather phenomenon.

If anything, the opposite thing is true. Each of the MD4, MD5, and SHA1 results are essentially exploits of design weaknesses: iteration insufficiency, too much traceable control over state given message words, weak and linear message schedules.

In the history of hash cryptanalysis, we continuously get better at exploiting these kinds of weaknesses, successfully exploiting differential analyses with smaller and smaller windows of opportunity (which is why SHA1 was such a big deal). But in the same way that you can foreclose entirely on a SQLI with parameterized query, or a memory corruption vulnerability with automatic bounds checking, you can also just make the message schedule (not understood in the era of MD4 to be that big a hinge point) strong and nonlinear.

It is very unlikely that the future of CS holds some reliable way to defeat bounds checking, and, for the same reason, you can find cryptographers like JP Aumasson (a coauthor of BLAKE and BLAKE3, with no particular reason to stan the older NSA construction) saying we're unlikely to break SHA2... ever.