Thou shalt have no other gods before the ANSI C standard 1447

It was an observation. Note the "if".

Note that many years of experience does in fact make it much simpler to get things through peer review, because you know how the game is played and what you should (and should not) write and say to make it happen. But you know that already.

Intentional ignorance again.

I'll try it one more time. The adversarial environment is not anything new. It is old. You have been told this by many people. You got examples. Not only were inputs constructed by adversaries "considered" they were used.

It is obvious to me and others that it isn't obvious you can't refute anything. It would take a bit of research to even understand some of the comments from some folks. And they are not going to help you :-)

They didn't botch the job.

You missed the humor? I feel sorry for you.

There was no failure.

Your entire argument is worse than bad, it "isn't even wrong."

Now if you happen to think you limited your discourse to some specific OS or some specific network flavor or some specific hardware you need to make that clear. If this is all about uSoft we already know the answer: they designed and marketed and sold exactly what their customers wanted. That's how the world works.

Will now remove tongue from cheek and try something more on topic.

About hashing: it has been around for a long time, as have many other bit mixing flavors of compression and information hiding. One could do a taxonomy, maybe someone has. Start with the top level split into transparent and lossy, split by clbutt of transform involved and-or by intended use, enumerate. Keep in mind that many things are related including but not limited to data compression, data protection, data verification, data transmission (lossy channel, slow channel, compromised channel), corrupted data recovery, and a bunch more I'm too lazy to think about right now. They are all, in a basic physics sense, similar. Start thinking about them from an information and entropy state of mind and they all have much the same characteristics, and fall into three obvious clbuttes.

All have vulnerabilities that can be attacked. Think about a one time pad. There is a simple and clbuttic attack: "You have the pad, I have the gun."

This thread morphed rapidly from a discussion of buffer overflow to the much more interesting and useful discussion of "how to create software that works." There is no technical solution to this problem, because it is not a technical problem. It is instead a problem of understanding cost benefit and then choosing how much one is willing to pay for what level of security, reliability and availability. The more you want of each of those, the more you will pay for your solution, and the longer you will wait for it.

This whole thread contains some excellent insights into how those trades have been made in the past, in different situations, and by different people and organizations.

Tongue now back in normal position (left cheek).

--

... Hank