To maximize the effectiveness of encryption in providing effective security assurance solutions, organizations must deploy it as part of a defense-in-depth security stance. Like any technology, encryption is plagued with pitfalls, mistakes, and traps that could easily provide an organization with a false sense of confidence in its security, while still allowing attackers to easily compromise the organization’s data. The common pitfalls, mistakes, and traps that an organization implementing encryption must avoid are:

• Algorithm Management

• Key Length

• Key Recovery

• Scope of Protection


The general mathematics behind an encryption algorithm is fairly straightforward. At first glance, writing algorithms seems to be very easy to do. In reality, writing secure algorithms is extremely difficult. The details of how the algorithm is assembled play an important role in its effectiveness.

Differential crypt analysis was first discovered in the mid-1990s as a method for cracking symmetric Key algorithms very quickly. Early on, the difference between algorithms that could be broken and algorithms that were secure was how the data was broken up prior to encryption. Something as simple as how the data is put into blocks determined whether an algorithm was secure.

A key lesson is to never, under any circumstances, trust proprietary algorithms.

Strong, robust cryptology is built in such a way that even if the algorithm is known, the cipher text is not breakable. The strength of the cipher text is based on the secrecy of the Key, not the secrecy of the algorithm.

With encryption, it is not possible to prove that an algorithm is secure; it is only possible prove that an algorithm is not secure through proper testing. Therefore, an algorithm’s strength is properly validated only by: publicly releasing the algorithm to experts in the field, then allowing those experts to closely examine that algorithm and to attempt to break it over an extended period of time (for example, a decade).

In an example situation, a vendor of hard drive encryption solutions recently attended a tradeshow; making broad claims about how secure the product was because the company had developed a proprietary, highly secure algorithm.

The vendor refused to provide details on how the algorithm worked, claiming that providing the details would weaken the algorithm’s security. This refusal, in essence, demonstrated that the algorithm had not been tested. The chance of a vendor producing a perfectly secure algorithm with no mistakes is impossible. In this example, since no one tested the vendor’s algorithm, the program was easy to “crack.”

In reality, with the use of a hex editor tool and an approval in place, a skilled computer professional could easily acquire the Key off of the system and decrypt all of the sensitive information. Of course, the vendor claimed that such a test was biased, as a normal attacker would have less expertise. Best practices, however, dictate that if an organization chooses to deploy a security product, it should deploy the product that defends against highly skilled attackers, rather than choosing a product that will only defend against a low-grade attacker.