Just Say No To Proprietary Cryptographic Algorithms

I was eavesdropping on the conversation while scanning email and I heard Smail say the product uses a proprietary polymorphic algorithm. Sorry, you lost me at proprietary, and I blurted out "It isn't secure," which completely derailed the conversation.

Mike Fratto

November 20, 2009

5 Min Read
Network Computing logo

One of the things about trade shows is that there are always those who have a new idea that they want to tell the world, and they expect the world to simply accept their claims. That was the case with Encryptstick, a product that installs on a USB or other mobile media device and provides encrypted storage for data. They had a nice little demo and the product seemed like it might be one way to carry encrypted information around with you, but it has a fundamental problem. There is no way to trust that the product will keep data safe.

Over the years, there have been many USB secure storage devices on the market. Some included a finger print reader to grant access, others a password. In most cases, when the storage was on the USB device, a successful authentication would decrypt and mount a hidden partition used to store the data. As the size of USB drives grew, they became more useful for everyday IT. What was often missing from many of these devices was a centralized management system so that IT could perform key management and remote unlocking functions. Encryptstick is in the same boat, though Mark Smail, VP of IT said central management is on the roadmap.

Then there was the show stopper.  I was eavesdropping on the conversation while scanning email and I heard  Smail say the product uses a proprietary polymorphic algorithm. Sorry, you lost me at proprietary, and I blurted out "It isn't secure," which completely derailed the conversation.

Smail asked why I said that, and I pointed out a few things. Creating weak crypto is easy and creating strong crypto is hard. Crypto algorithms will weaken over time due to advances in cryptanalysis and computing power. There is no security benefit in relying on the secrecy of the algorithm, known as Kerckhoff's principle or Shannon's maxim. Let me take these one at a time.

  • The need for public review is one of the reasons why NIST has sought public review of algorithm candidates for when selecting algorithms. Testing the strength of a cryptographic algorithm isn't like testing the tensile strength of metal. Cracking an algorithm takes a thorough understanding of cryptosystems, the algorithm to test and problem solving skills. The only way to test the strength of an algorithm is through public review, because different people will approach the analysis in different ways. All it takes is one person to find a weakness using an analysis that the algorithm authors hadn't thought of. The hope is that through public review, the analysis will reveal weaknesses and tell the author whether the algorithm has enough merit to undergo further refinement addressing the weaknesses or should just be abandoned.

  • Of course, the strongest algorithms stand the test of time and repeated attacks but with each new type of attack and with more computing power, the chance that an algorithm will be weakened increases. Encryption algorithms like DES 56 and RSA (at varying key lengths) have been successfully attacked. More recently, one-way hash algorithms like MD5 and SHA-1 have been weakened as well. No algorithm stands forever.

  • Finally, an algorithm will be discovered regardless of how well protected it may be. Skilled analysts can decompile software to discover the algorithm, pull the code from RAM or ROM, or even reverse engineer the algorithm based on knowledge of the input, output, and key.  All I have to do is get the algorithm is buy the software. The algorithm can't be kept secret (arguably, neither can the key, but that is a different discussion).

The percentage of the population that uses cryptography is large. The percentage of those that understand cryptography is smaller, the percentage of people who can create and test cryptographic algorithms is much smaller. It's one of those areas that through open analysis by qualified experts, we can be assured that an algorithm is strong enough for our needs. Thinking that you can come up with a strong algorithm on your own that hasn't been tested is foolish. The algorithm maybe strong, but how do I know it is? How do I know 3DES or AES is strong? Because people in a number of walks of life and much more qualified than I say it is. How do I know that DES is not strong, because others have demonstrated they can recover the key -- crack the code -- in a reasonable amount of time.

So where does this leave us with Encrypstick? Don't trust it. The algorithm may or may not be strong. Who knows? There are other products on the market that offer similar key management functions, TrueCrypt for example, that also uses publically assessed algorithms. There isn't any need to use a proprietary one. Obviously, using a publically assessed algorithm doesn't automatically mean the software provides the security functions it claims. There can be other weaknesses even when an algorithm is implemented properly.For example, in 2008, the Debian Linux implementation of a pseudo-random number generator (PRNG) meant that the platform generated weak keys in packages that used the PRNG like OpenSSL and OpenSSH. There are a lot of issues that need to be tested, but starting from a foundation of  trustworthy algorithms is a big start towards trusting the rest of the application.

To the makers of Encryptstick, if you want people to trust that your product is secure, you must open the algorithm to public review. No NDA's. Open. Take all the legal means you need to protect your intellectual property such as getting a patent, but if your algorithm is that strong, it will stand public scrutiny. Who knows, you might get feedback that makes it better.

About the Author(s)

Mike Fratto

Former Network Computing Editor

Stay informed! Sign up to get expert advice and insight delivered direct to your inbox
More Insights