To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
The short answer is no, and this applies to all but the proverbial rocket scientist. Developing Web applications that are bug-free and secure is a difficult enough task without the added complexities of writing your own cryptolibrary. Why re-invent the wheel, particularly when creating your own security toolkit is a very difficult and lengthy task? Besides, most people, myself included, would not buy or knowingly use an application that relied on propriety, untested encryption algorithms because it wouldn't have had adequate testing and validation against established standards to provide the necessary security assurance.
The most popular and common cryptographic algorithms have their source code available for public inspection and have been scrutinized and analyzed by both white hat and black hat experts. This ability to review how a cryptographic module and its cryptographic algorithms are implemented is vitally important. So much so that there are legislative restrictions that require federal agencies to use only products tested and validated through the Cryptographic Module Validation Program in any IT systems that include encryption products.
Interestingly, even FIPS 140, a government standard that specifies encryption requirements, doesn't guarantee that a module conforming to its criteria is secure or that a system built using such modules is secure. It is this last point that makes many security purists argue that open source security is always more secure than proprietary security, as one can look at the full source and check whether the encryption algorithms are implemented correctly.
Poor design or weak algorithms can render a product insecure and place highly sensitive information at risk. In my recent article on the Debian flaw, you can see how a good, but poorly implemented, open source cryptographic module led to a serious and far-reaching vulnerability. Although the Debian flaw only directly affected Debian and other Debian-based distributions, such as Ubuntu, other systems could be indirectly affected if vulnerable keys generated by Debian systems had been imported into them. Similar poor implementations have caused a number of problems, including vulnerabilities in Kerberos, the X Window system and the Network File System protocol.
Hopefully it's become clear why it's important to use the tried and tested cryptography libraries; they will have the cryptofunctions that your application may need, such as SHA-1, RSA, DH, Blowfish and DES. The OpenSSL cryptolibrary, for example, implements a wide range of common cryptographic algorithms used in various Internet standards and is well documented. Choice of one cryptolibrary over another is largely a matter of the programming language you're using and licensing issues. You should choose the library and algorithms that best suit your purposes and ensure that you implement them correctly. This, in itself, will require rigorous testing.
If you have an interest in cryptography away from your role as a developer, then you should study the math involved in cryptography and then see if you can break the more basic systems. I would start by reading Applied Cryptography by Bruce Schneier, which explains a lot about what goes into a cryptography algorithm, and then study the code in the Crypto++ library for the algorithms you're particularly interested in.
More recommended reading:
Read Cryptographic Libraries for Developers by Diana Kelley and Ed Moyle, both of whom are frequent contributors to SearchSecurity.com.
|
