The Past
Over the years I’ve worked with many Cryptology algorithms. In the mid 80’s and early 90’s for example, everyone, including myself. Where always trying to invent there own “unbreakable” encryption. Passing them over BBC, IRC, and, ICQ. I guess they where fun to test, break and re-make. But otherwise, nothing more than educational.
Most cases of “custom” encryption or hashing algorithms that where passed to me. Ended up being various methods of hiding bit shifting, simple character rotating, and, the infamous, magic key, security by obscurity algorithms that as soon as there de-compiled, or, used in the wild are pretty much useless.
The good thing that came out of the early 80’s and 90’s mess however, at lest, in my opinion, was the standardization of various methods of Cryptology. Such as, MD5, SHA1, DES, and, AES. With this came a basic terminology such hashing, and, encrypting. Followed by a basic understanding for those not directly in the field. Such as Application Developers, Web Developers, and, Database Engineers. That, plain text data, compiled data, and, database records are not safe without the help of the aforementioned methods.
The Present
Like most large area’s of standardization, Cryptology has suffered from painful levels of fragmentation. This amplified by the fact that Application Developers, Web Developers, and, Database Engineers often end up using what they know has always worked rather than what might be secure for the time. Worse yet, companies often enough will use what consumes the least amount of resources on the system or server rather than what might be secure. While this is also true in most area’s which also suffer from fragmentation. It seems to be painfully worse with Cryptology.
You could argue this is because Cryptology does not have a fancy marketing scheme such as HTML5 did. Or, companies, to put it bluntly, are cheap skates. However, that would only be part of the problem. The major issue, as cheesy as it sounds, is Cryptology is hard. What to use, when to use it, and, how to use it. With a client, or, a boss breathing down your neck. It’s becomes easy to reuse code rather than verify that it’s still valid. Besides, If it’s not, how do you change it across an entire company? Every product? Every site? S.C.A.R.Y. Without a doubt, Database Engineers, have it the worst. Rotating a hashing algorithm or Cryptology method in a production database is an outright career ending nightmare.
Of course, hackers take advantage of these facts. They know web developers, and, application developers, and, database engineers of the world are not security experts. Hackers know that most companies will always take the most profitable road, not the most secure one. The common phrase from Administration is “Who would want to hack us?” and “We have not been hacked!”. This is predictable behavior, this is also exploitable behavior.
We are entering what will be known as the, “Cryptology War II”. Reminiscent of the 1970's "Cryptology War". Only this time, it's on an unknown battlefield with soldiers, who may not know they are soldiers. With the constant onslaught of zero day exploits in released software and web applications. With aging hash’s and cipher blocks held in production databases. The grunts on the front lines of this battlefield are the Web Developers, the Application Developers, and, the Database Engineers of the world. How many business do you think understand this fact. Especially when they have a client screaming and a developer who wants to research more secure methods? Worse yet, this war is amplified by the “Privacy Wars”. The fact that the NSA, and, the GCHQ strive to shatter any faith in standardized Cryptology puts us at risk of regressing to the early days of everyone trying to create “unbreakable” encryption methods.