Many times organizations try to go about implementing their own encryption schemes thinking that the relative obscurity of the encryption scheme might end up helping obfuscation. The senior management sometimes (incorrectly) believes that such obfuscation might provide additional security. There is sometimes also a perception that such “additional security” has no trade-off associated with it if the organization believes it has strong development teams to be able to support such encryption.
The reality, however, is that the use of a self-implemented encryption scheme results in the organization assuming a higher risk than using a publicly released and open encryption mechanism. Let’s see what are the Top 4 risks associated in implementing your own protocol.
Bugs- Invariably, some aspects of encryption are incorrectly assumed to be secure. When the protocol used is proprietary,
Lack of Peer reviews – The adequate amount of peer reviews are generally not performed as compared to those done for an open protocol. The more the experts that look critically at a protocol implementation to attack the encryption scheme, the more secure it tends to become.
Esoteric Knowledge – Seldom are the testers of an organization as well equipped to test an encryption scheme as are the developers. The developers always want to write code that they think is correct. The QA teams are the ones that keep them honest. Due to the sheer complexity of the code as well as the innumerable aspects of an encryption scheme that can be attacked could limit the QA teams’ capability to point out the right amount of issues or even design errors.
Maintenance – Also, maintainability of proprietary encryption schemes does not happen as well as it happens for openly known encryption schemes. Generally, open encryption schemes such as CBC, CTR, AES, etc. are more commonly used than their proprietary counterparts. As more and more situations occur where an encryption is used, the more errors are likely to be identified. Thus, the ongoing maintenance of the sanity of the encryption scheme is possible. With a proprietary protocol, such maintenance cannot be performed due to lack of usage variety. Moreover, it is expected that the code is assumed to have matured when in reality it isn’t.
Always, implement openly known and available encryption schemes that are known to be secure. Never try implementing your own algorithms to achieve encryption. Such schemes are called Encraption!