Slashdot Mirror
How To, When You Have To Encrypt Absolutely Everything?
Dark Neuron writes "My institution has thousands of computers, and is looking at starting an IT policy to encrypt everything, all hard drives, including desktops, laptops, external hard drives, USB flash drives, etc. I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives, but I am concerned about overhead and speed penalties. Does anyone have experience and/or advice with encrypting every single device in a similar situation?"
I am looking at an open source product for Windows, Mac, UNIX, as well as portable hard drives ...
I think you're going to find most people advising you to choose TrueCrypt which boasts:
I think they're on version 6.1a and I have been impressed with them. You may want to try benchmarking the various encryption algorithms it offers.
... but i am concerned about overhead and speed penalties.
Aren't we all. I mean, no one wants an Office Space like scenario where every day before you leave you have to wait for the damn little bar to cross the screen to save your progress for the day. You have another option which is to wait until the drive manufacturers build all that into the hardware's firmware so that it is as fast as they can make it.
... I also would feel very uneasy if someone assured me they had a method to do that. Drive encryption is one of those seemingly trivial but necessary reasons why companies have many system administrators and not some automagical solution.
I wouldn't recommend waiting that long, however.
Here's my formal suggestion: do a small test on a few users or even a few devices no one depends on, some USB drives, etc. Use them yourself and see what kind of overhead (for both user and device) we're talking about here. Then weigh that with how much comfort you get with universally encrypting everything. If A is greater than B (with a sinister sounding name like 'Dark Neuron' who knows?), draft up a plan. Otherwise, just wait until you have the funds to upgrade the hard drives to those with the built in encryption.
I do not know for certain but I do not believe there is a painless push-across-the-network way to do this
My work here is dung.
I've heard that full fs encryption on higher end computers has a negligible performance impact (cpu can generally keep up with the hdd) but on lower end machines esp. netbooks, the performance impact can be appreciable. Here is an article with benchmarks
Mod points: Guaranteed to remove your sense of humor.
Side effects may include gullibility and temporary retardation
I can't tell, are you joking? With all the sarcasm around Slashdot it's sometimes difficult to tell if someone is being snarky.
The scenario you mention wouldn't happen unless a half-baked encryption scheme was used. HP, RSA, IBM, and even Truecrypt all have recovery options ranging in levels of difficulty to implement. RSA's key management tools are quite handy but you definitely pay a premium for them. HP's are clunky like all HP software, IBM has been doing it for years but again you pay and arm and a leg.
With Truecrypt you create two to three thumbdrives when you do the initial encryption, two of them store the master encryption key and the third has whatever key is needed for authentication depending on how you want to deploy it. The only fault I have with Truecrypt is that there are a dozen ways to deploy it so you have to read and plan very carefully before deploying it on any level.
Once you have your flash disk you copy its contents to an encrypted folder on your SAN somewhere and keep the flash drive in a properly fire-proof safe. One flash drive has the keys for over a hundred machines with room for plenty more, keeping two copies ensures that a flash drive dying won't leave your data inaccessible during transport to the server and should the SAN experience some sort of data loss you can go back to the flash drive to recover keys.
Encryption is pretty scary as your keys are extremely important as you mention, once the key is lost then so is the data. So you take a few precautions ahead of time and then you don't need to worry.
Hard drive encryption isn't meant to protect against social engineering attacks. It's meant to protect against attacks that don't require social engineering, like stealing or cloning a database server's drives for the information. More than anything, it's meant to provide reasonable assurance that if one of your employees' computers gets stolen by a common thief who just wants to sell it for the cash value, somebody else down the line won't be able to read the data in the drive and take advantage of it.
Are you adequate?
There's a huge difference. When you see numbers like "128-bit," you're dealing with a symmetric encryption algorithm (e.g., AES). When you see numbers like "4096-bit," you're dealing with an asymmetric algorithm (e.g., RSA).
See the NIST Recommendation for Key Management (PDF), page 63. For example, to get RSA that is "equivalently" secure (for some predicted meaning of equivalent) to AES-128, you need a 3072-bit key. The table is explained on page 62.
As an aside, the comparably small key sizes that asymmetric elliptic curve cryptograph (ECC) can use, illustrated on page 63, are one of the reasons that ECC is so valuable.
Nobody deals with that, for the moment. I don't think the hardware solutions deal with that for every case, either.
I've heard of some possible solutions being thrown out there - including a CPU "disabled cache"-type software solutions - but there's nothing being sold yet.
I said no... but I missed and it came out yes.
TrueCrypt has several options. The way I have it configured, the TC volume is automatically unmounted when I suspend, and I need to re-mount it when the notebook wakes back.
I understand the password is not in RAM anymore after a suspend. These are the options I use:
"SaveVolumeHistory" = 0
"CachePasswords" = 0
"WipePasswordCacheOnExit" = 1
"WipeCacheOnAutoDismount" = 1
"StartOnLogon" = 0
"MountDevicesOnLogon" = 0
"MountFavoritesOnLogon" = 0
"DismountOnLogOff" = 1
"DismountOnPowerSaving" = 1
"DismountOnScreenSaver" = 0
"ForceAutoDismount" = 1