Webmaniacs - Cryptography and Dentistry
On Tuesday I took in a workshop on Cryptography by Dean Saxe. Dean is an impressive character with a head stuffed full of knowledge and spilling out everywhere. He obviously knew what he was talking about. As a topic, cryptography is so impossibly complicated and intricate that he could not do it justice in a 50 minute session. Most discussions about cryptography center around keys, algorithms and best practices - and this was no exception. Dean recommended against relying on CF's own encrypt and decrypt functions for anything but the most rudimentary encryption. In fact, he probably didn't even go that far. That tidbit of advice is common from almost every security pro I have ever heard mention the subject. When it came to discussing keys it was like a trip to the dentist.
The discussion of keys and secure storage was a dizzying array of circular decision making. Where do I store the keys? Are the keys themselves safe? Are the keys encrypted? Where do I store the keys to unencrypt the keys I have stored? How do I secure those keys? If tweedle beetles battle with paddles in a bottle on a noodle eating poodle in a puddle, would that be a poodle puddle noodle bottle tweedle beetle paddle battle (Thank you Dr. Seuss)? It seems we are all doomed eventually to have a post-it note password stuck to the underside of our desk. I could not help but think of the puzzle penguin made of wood I had as a child - each penguin containing another smaller penguin.
In any case, after some discussion of hardware solutions and the Java keystore tool, Dean's final suggestion was, and I quote:
It only struck me as funny because it seemed like the concluding sentence of the presentation, as in "Hey this stuff is really really hard and complicated so don't go there if you can help it." As a final salvo to an audience straining to learn about encryption it took the wind out of our sails a bit.
In a perfect world we would all have fancy pants DOD encryption where an armed marine stands guard over our keys in a vault that no one but Nicolas Cage could possibly penetrate. But I don't think that the daunting challenges of PCI compliance should keep us from doing things like encrypting passwords (for example). I suspect that Dean would agree with me.
Sometimes discussing encryption causes us to throw up our hands because it seems there are dangers, insecurities and vulnerabilities around every turn. No solution seems both secure and manageable. My view (with PCI compliance as an exception needing additional attention) is that encryption is another obstacle in a layered defense. Sure, in an easily managed, unobtrusive form it's imperfect. I think the basic question for most projects is the risk and cost question - how secure do we have to be and how secure can we afford to be. So keep hashing those passwords and don't let the insecurity of your algorithm deter you (at least not until you can afford an armed marine).
Finally, let me say that I thought the presentation was excellent and I picked up a number of nuances on cryptography of which I was previously unaware. If you need someone to review your system for PCI compliance I'd say Dean would be a great choice.
3 Comments
-
Sounds handy. I spent hours banging my head on Adobe's useless CF8 Encrypt() livedocs the other day... they're cleaning it up following an email I sent, but even the one they updated isnt very useful.
CF8 now supports several public/private key encryption algorithms, which takes care of a big chunk of the security concerns regarding the key, but the documentation has zero information on how to actually *use* it. -
JC,
Thanks for the comments. Dean will chime in here pretty soon I think and add to the discussion. But the knock on CF's native encryption function has always been that it is behind the curve a bit I think.
-mk -
The challenge with CF is really key management. The APIs aren't there and are not flexible enough (IMHO), so you're better off using native functions of the JCA/JCE to handle all of this under the covers.
To be fair, my biggest gripe with developers and encryption is the use of encryption to solve problems often leads to bigger problems. One must solve a specific issue (data confidentiality, integrity, authentication or non repudiation) or a collection of the above with crypto. When crypto "magic faerie dust" is used in every application "because it makes it more secure" that is a big red warning sign. Crypto != security, but some types of security may be obtained through the judicious use of crypto.
Finally, with the key storage question, it is all a matter of risk tolerance when deciding how to store and manage keys. What is right for a PCI DSS environment is not necessarily correct for other domains. Only you can tell what your risk profile is and, therefore, decide the best way to manage encryption key storage, inarguably the hardest part of using crypto, in your own code.
-dhs
Sites to Watch
Aggregators
RSS
