June 15, 2009 5:19 PM PDT
On encryption and why it's overrated
I ran across a recent blog post by storage vendor Cleversafe titled "Three Reasons Why Encryption is Overrated," and as I suspected it generated a lot of discussion in online forums (LinkedIn, Google Groups, log-in required for both) dedicated to those issues.
Beyond the sensationalist headline, the post does raise some interesting points for consideration on the topic of encryption.
- Future processing power--In the future, malicious hackers will be able to crack older encrypted files due to increases in processing speed.
- Key management--An encrypted file has a key to unlock it. Lots of files means lots of keys. Lots of anything equals management headaches.
- Disclosure laws--Such laws mandate that data breaches are reported. Whether or not that exposed data is safely encrypted or not doesn't really matter at that point--the court of public opinion has branded you guilty.
Distribution or dispersal of data (Cleversafe's approach) is certainly one way to deal with emerging security threats, but it may not be the right way for everything. The important thing is to start looking at new technologies and methods to determine what's right for your business and technology strategy.
Follow me on Twitter @daveofdoom.
Dave Rosenberg dishes up "Software, Interrupted" with nearly 15 years of technology and marketing experience that spans from Bell Labs to multiple start-up IPOs to open-source enterprise software companies. He is co-founder of MuleSource and currently serves as the general manager of Hardy Way. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can contact Dave via e-mail at softwareinterrupted@gmail.com or follow him on Twitter @daveofdoom. 
In these cases, the best solution is always prevention. If you take no chances with exposing data (and making it difficult even for yourself to access the data), then the chances of a hacker getting to it are slim to none. Back it up with a good IPS and lots of conveniently-placed killswitches for emergency shut-off, and you'll be prepared.
That said, a lot of security audits and compliance standards require encryption, so sometimes you can't avoid it entirely (although once a hacker is in the system, finding the encryption/decryption code is often a breeze). I've found that the best encryption is a nice-n-solid, proprietary method with multiple encryption passes (so if you "crack" the first layer, the decrypted contents still look like a failed attempt). Encryption won't keep out determined people, but it increases the time they need to be in the system in order to gather all the pieces of the puzzle, and that buy you enough time to yank the plug.
- by dhavleak June 16, 2009 12:57 AM PDT
- Dave,
- Reply to this comment
-
(5 Comments)I kinda disagree with your entire article (well, ok point #2 is valid) :)
I'll start with #3 since that's probably the more egregious error:
----------
Sure - disclosure laws mean that if you have a leak, you can't escape getting some egg on your face. Here's what it gains you though: your customer data is still safe for a good amount of time, if the leaked data was encrypted. This gives you time to notify your customers. If the data is stuff like credit cards etc., it gives you time to issue new credit cards (or tell your customers to replace those cards etc.) before something bad happens. In other words -- it's a *huge* damage-limiter. It's a *huge* mitigating factor to the fallout of a data breach.
Next, I'll address #1 since that's a pretty key point:
----------
Yes - crypto keys are only considered secure for a certain period of time. But these times are somewhat easy to predict (because we have an idea about the pace at which microprocessors get faster, and we know the computational effort required to brute-force compromise a key). Black swans like quantum computing notwithstanding, of course. But even then, the mitigating factor is clear. Using current knowledge, you can estimate the cost involved in brute-forcing a particular key within the next X years. If that cost is less than the value of the data you are trying to protect, you need a longer key.
The real problem you should have mentioned as #1 instead, is the fact that a crypto system is only secure (usually through peer-review) until it is proven insecure. If you use a crypto system today to secure stuff, and tomorrow someone comes out with an algorihmic method of scoping down the computational cost of brute-forcing the key, you are hosed. Usually this will come as some flaw in the hashing algorithm (resulting in collisions) or some way of reducing the number of guesses you need to take to deduce your private key from your public key, etc.