Laurentiu Cristofor has an excellent blog post, Who needs encryption?, which presents some point blank facts about encryption and the correlations you can draw from those facts. This post isn't a SQL Server or even a database specific post. It's about encryption in general.
I love his Fact #1: Encryption does not eliminate the need to protect some data. I was recently talking with some peers about whole disk encryption technologies. The idea behind whole disk encryption technologies is if someone were able to steal the hard drive (such as by taking a laptop), as long as the hard drive was powered off, by powering it on they wouldn't immediately get access to to the data. They would have to decrypt the hard drive. Well, there's two ways to go about this. You can either try and decrypt the whole hard drive, or you can try and decrypt the portion that stores the key to decrypt the whole hard drive. Any serious attacker is going to go after the latter because once you get it, you get the whole hard drive. And that's the point. You no longer are in the business of safeguarding all the data. The encryption does that for you with the exception of the key itself. You must safeguard it. The discussion with respect to whole disk encryption turned to wanting to make the encryption on the key weaker than on the rest of the drive because people were having to enter in too many combos of characters when they forgot their password and the admins needed to unlock the drive. My point was that whichever was weaker, that was the level to which the hard drive was effectively encrypted. Therefore, weaking the encryption algorithm on the key to make it easier for customer support reps and end users to being able to unlock the hard drive in the case of a forgotten password wasn't a good idea.
Fact #4 is a sticking point for me, too. When developers who aren't very knowledgeable on encryption say, "Hey, I'll just build an encryption algorithm because I don't feel like using one of these others. How hard can it be?" that drives me crazy. A lot of developers understand that here laziness is the right approach. If it's a rock-solid algorithm that has undergone the scrutiny of the crypto community and survived, it's a good candidate. Just figure out how to implement it. Unless you have advanced degrees in mathematics and time in the field, it is extremely arrogant to think you can design an algorithm better than what's already out there. Granted, you might, but given some of the algorithms developed, you've wasted a lot more time doing so when you could have been doing other activities for your organization.
Technorati Tags: Security |
