Slashdot Mirror
Resisting the PGP Whole Disk Encryption Craze
alaederach writes "I run a lab in a non-profit academic life sciences research institute. Our IT recently decided it would be a good idea to use PGP whole disk encryption on all of our computers, laptops and servers and picked PGP's suite of software. The main reason is that a small subset of our researchers work with patient information which we obviously are mandated to keep confidential. My lab does a lot of high-performance computational work (on genes from Tetrahymena, no humans here) and I am concerned that the overhead of complying with our ITs new security policy will be quite detrimental to my research program. For example, dynamically reallocating a partition on a PGP encrypted disk is apparently not possible. Furthermore, there is some evidence that certain forms of compression are also incompatible with PGP whole disk encryption. Interestingly, it is hard to find any negative articles on PGP, probably because most of them are written by IT pros who are only focused on the security, and not usability. I therefore ask the Slashdot community, what are the disadvantages of PGP in terms of performance, Linux, and high-performance computational research?"
Truecrypt Whole Disk Encryption has less than 1% over head. I can't see the problem. Surely the patent and IP information security outweighs this minimal overhead.
Furthermore, there is some evidence that certain forms of compression are also incompatible with PGP whole disk encryption.
What do you mean by "incompatible"? At first glance, you seem to mean that there are certain file formats, making use of compression, that cannot be stored on the encrypted drive. That certainly can't be true.
Swedish plasma phys. PhD student; MSc EE; knows maths, programming, electronics; finance interest; seeks opportunities
Do you have any numbers to back this up?
Here's some numbers: http://ask.slashdot.org/comments.pl?sid=1012285&cid=25566509
Make of them what you will :)
"Marketing is not a science even if its an Open Source project"
Run some tests on a drive. Run TrueCrypt, re-run the tests, look the difference in CPU load and performance and then try and work out where the 1% number comes from.
Personally I think its based on averaging time across when you aren't using the machine.
An Eye for an Eye will make the whole world blind - Gandhi
TrueCrypt claim a 1% overhead. With multi-processor machines, I doubt that's even accurate anymore.
Yeah - with version 6 of TrueCrypt, they introduced support for multiple cores, with almost double speed on a dual core system over a single cores system.
I use a TrueCrypt encrypted USB disk to store and run VMWare virtual machines and I see no difference in speed over using a non-encrypted USB disk (same model).
There are several reasons why a policy of having all disks encrypted is bad:
1. Sensitive data should not be stored on a computer that can be carried away or easily accessed, with or without encryption.
2. Blanket security measures just means that the employees will find ways around them which usually means that you probably end up with bigger security problems.
3. Failing or failed disks goes from a serious problem to a critical problem for recovering data.
4. If you are running I/O "happy" software you are going to take a perfomance hit.
5. It's not a "green" solution since the encryption is done in software and the computer is going to use more power.
Oh, and let me re-iterate: Sensitive data should not be stored on a computer that can be carried away or easily accessed, with or without encryption. Just look on how MI5 left laptops all over the place.
The policy we use when working on sensitive data is that it's all stored centrally with rigorous security measures for accessing it and the only way to access the data is through a Sun Ray thin client. That way we minimize the risks for electronic information leakage, ie. someone mailing information etc.
--- Reality doesn't care about your opinions, it happens anyway and if you are in the way you'll get squished.
I work with the DoD on a classified program. You're right, we don't use encryption on any of our desktops, but the only reason is because you go through 2 security gates with guards, then finally enter a closed room with a giant digital lock with a badge swipe and keypad on the door, not to mention a giant separately digitally controlled deadbolt in addition to the digital lock.
You better bet your ass that we use whole-disk encryption on any machine that would leave the building, though (such as laptops). And those are unclassified!
I used to have my laptop hard disk encrypted (using LUKS) but the hardware is getting pretty old now and I was starting to have problems with timing-sensitive applications such as audio and video. I think it was more bad timing interaction between the crypto layer, LVM, ext3 and the memory cache than raw throughput issues. I had a lot of layers and they weren't quite talking to each other right. Most of the time this was fine but occasionally it would add a tiny bit of latency to a disk request and audio would skip or video would jitter. It drove me round the bend.
Now, with everything else the same but minus the crypto layer things are much better. My laptop isn't as secure but then again I don't move it around nearly as much any more and don't have that much of worth on here anyway. Whether or not to apply something like this depends entirely on the situation.
I don't understand people who think that if they encrypt something it automatically becomes secure. For that data to be of any use to someone it will need to be decrypted and relevant people given access, so that destroys the notion of defacto encryption for security right there.
Encryption assumes that bad people are going to get access to your data whatever happens, and if you are using whole disk encryption then you really need to be seriously asking yourself who has physical access to your disks and where your data is located. That needs to be sorted out first, and once it is with data held centrally, I doubt whether disk encryption will be needed. You will probably need some form of encryption between the data and the remote users though. Using full disk encryption gives you something else to go wrong, is a variable in performance impairment you probably can't account, is something else to support for and will almost certainly be unnecessary once you've taken other steps first.
If you're keeping confidential patient information where it would be a Bad Thing(tm) if it ever got mislaid (even if it is encrypted, you don't want a computer with stuff on it lost I assume), in the name of all that is holy, please centralise your data and vet access. Stop people from passing around Excel spreadsheets of data, regardless of when and how it is encrypted.
I really am aghast as to how stupid people are about how and where their data needs to be protected. PGP is the wrong solution here, if you can call it a solution.
actually there's not much disk hit. The CPU loss does exist but isn't awful. I don't do anything that computationally intensive on my laptop.
I ran quite a few tests on my solution; I don't really care if some other software costs you 50% overhead and makes it impossible to use compression software [impressive kernel hack?], for me I lose about 20% write speed 30% read speed, and that's only for sustained read/write.
Day to day use? Didn't slow down a bit. Just as responsive. Battery life? Lost about 10 mins. CPU? Still idles at 0.00.
The cost to me was $20 for the encrypting hdd (that's the differential) and a bit slower for copying massive amounts of data. The upshot? When my laptop with all my financial documents, years of personal email, credit cards, and login credentials for root on some servers I'm responsible for was stolen last year, I lost no data and no one else gained any. The Debian ssl bug hurt me more than that loss (the laptop was actually insured).
The benefit to my using encryption is marginal. So's the cost. The hdd was a toy to play with. The software was a checkbox during installation.
So no, I wouldn't do this to a work computer unless there were a good reason (like being a laptop). But for my personal machine it makes a lot of sense.
93rd rule of Slashdot: No matter how obvious my sarcasm is, my comment will be taken seriously by someone.
If you've got enough money lying around, you could get a Blet--er.. probably shouldn't use the code name. You could get a MR10is "VAULT" RAID adapter from LSI and IBM (for SAS and sata drives). I got to QA test it, put it through its paces. It seems to be pretty decent (now) and lets you fully, transparently encrypt your hard drives.
They're over $1,000, but if performance and security are that important to you it may be worth it. The VAULT only supports internal drives, but I think a morg--er.. I don't even know what the non-code name for those cards are... I think an encrypted version of the MR10m, which is for external SAS/SATA hard drive enclosures, is in the works.
Skiffy is Spiffy, but Ort is tort.
I'm not a network administrator, though I used to be. Now I own the company, and the policy stands unbreakable, period. There is no compromise.
In return, 5 years of zero security breeches, zero data loss. I don't know about you, but I like to sleep well at night--and in my position, that's already difficult enough.
And of course the user's needs are seen to, but not to the detriment of security under any circumstances, ever.
"Performance" is only a valid topic after addressing reliability.
In my company, we gave up on PGP's whole disk encryption after it consistently locked up (but was ok after many multiple reboots) on both Panasonic Laptops and Lenovo Laptops.
For the last few months, we have been trying TrueCrypt on the above brand laptops and also and HP desktops with no issues (as of yet).
If you load RAM by opening a bunch of simultaneous Windows and then run some mathematical loops that represent the kind of calculations your environment demands, you can then determine whether the overhead of TrueCrypt (or whatever) is worth the security benefit.
Good luck.
No matter where you go . . . there you are. - Buckeroo Bonzai
Live Long and Prosper - Thanks Leonard. You are missed.
This works fine when everybody is using fairly standard software.
But it fails miserably when you are in a true R&D environment.
I worked in a Lab when an "edict" occurred that only windows PCs could be connected to the corporate network. Couple of dozen scientists putting in purchase orders to replace old but functional equipment in the $100k to $10m price bracket with the justification "drivers only available for , need to upgrade equipment to get PC support" and firing them up the management chain and someone saw sense very quickly.
It was actually rather amusing to watch (I wasn't affected - my group had our own completely independent network with independent connections to the world and my corporate PC was a bog standard supported (R&D) machine). A few rumbles of discontent when the email came around and then someone had the bright idea of deciding to cooperate with the edict rather than complain to fight it.
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
Fine, as long as you work my hours.
Of course. That's why we're support.
I've gotten up early to make changes, and I've stayed up late to make changes. It's part of the job.
I've never (ten years or so) had a local hardware issue extend into the host network. It seems to be fairly hard to do that if you're not an idiot
I guess you're not an idiot :)
Mostly, I'm talking about PHB-types that bring in a Linksys wireless router and plug one of its LAN ports into the building network. We also used to see issues where people bridge the company wireless network to the wired network, causing all sorts of issues, too.
Did you know that PGP WDE isn't officially supported on RAID configurations? I think it says a lot that the product worked in your environment, but a 12-disk RAID 50 configuration isn't exactly the sweet spot for a product targeted at laptop users.
No surprise that performance would be poor given that WDE is neither tested nor optimized for that use case. ...yes, I work for PGP.