Unless otherwise noted, articles © 2005-2008 Doug Spencer, SecurityBulletins.com. Linking to articles is welcomed. Articles on this site are general information and are NOT GUARANTEED to work for your specific needs. I offer paid professional consulting services and will be happy to develop custom solutions for your specific needs. View the consulting page for more information.


Testing Encryption

From SecurityBulletins.com

Jump to: navigation, search

Testing Encryption

(c) 2006 - Written Sept. 2nd, 2006 by Doug Spencer

During my security consulting experience, I have seen many security product vendors selling security products with some type of encryption. Sometimes it is a good encryption system, other times it is not. There are a couple of basic tests you can do to confirm that an encryption system is more than a substitution cypher. Note that this doesn't prove that it is effective encryption, which takes far more in-depth analysis to confirm, but it will help to keep you from getting completely bamboozled by a completely trivial system that can broken in 5 minutes. Here are three items you can look for.

  • Effective encryption should generally produce output that is nearly random. This can be used to your advantage when testing encryption. An easy test is to use a compression program, such as GZip, ZIP, WinZIP, ARJ, or a similar program. Compression programs look for repeating patterns within a file. If the "encrypted" output compresses more than a minuscule amount, then most likely it is a substitution cypher, has insufficient randomness in the seed values, or is a simplistic algorithm. Regardless of why, an encrypted file that can be highly compressed is not one that I would count on to protect my data. If you compress the source data, and it compresses the same amount as the encrypted data, it is most likely a substitution cypher being used, which can be easily decrypted with almost no effort.
  • Another item you want to look for when evaluating security is proprietary encryption algorithms. Places that believe they can write an effective encryption algorithm from scratch are usually wrong. Most people should stick with an algorithm that is well known and well tested.
  • Finally, you should be able to see the code for the algorithm that is used to encrypt the data. Having the algorithm available should not compromise the effectiveness of encryption. If it does compromise the encryption, or the vendor claims it does, then the encryption is NOT strong encryption. Remember, the algorithm is distributed in binary form that the computer can process. If someone spends a bit of time, they can disassemble the code and determine the algorithm.

To fully check an encryption algorithm requires in-depth analysis of the algorithm, including what amounts to a mathematical proof of the algorithm. Additionally, the source of randomness must be checked to verify that the random data is truly random. Also, the specific implementation of the algorithm must be checked. Vendor proprietary changes to a standard algorithm should be especially regarded as suspect.

Personal tools