Slashdot Log In
Resisting the PGP Whole Disk Encryption Craze
Posted by
samzenpus
on Thu Oct 30, 2008 03:59 AM
from the what-do-you-think dept.
from the what-do-you-think dept.
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?"
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Overhead (Score:5, Interesting)
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.
Repeat after me (Score:5, Interesting)
"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.
Parent
Re:Repeat after me (Score:5, Funny)
"Marketing is not a science even if its an Open Source project"
Parent
Re:Repeat after me (Score:5, Informative)
Parent is on the right track, imo. Submitter should work with the IT dept to assess the impact of this.
Setup two machines running the same processing task that is actual work that he does, one with encryption and one without. Compare the difference in processing. If the performance loss is acceptable, all done. If it's not acceptable, submitter needs to start agitating now that this will seriously hamper his/her ability to do the job, and push IT to come up with a different solution.
A previous employer rolled this out, and after my work productivity got killed, i found their assessment consisted of two guys opening MS Word, making some edits, saving, and exiting word.
Parent
Re:Repeat after me (Score:5, Insightful)
RTFA FTW!!!
The Submitter him/herself doesn't work with sensitive info, just other dept's. IT is enforcing an overly broad solution on everyone, with considering the downside. I agree with you that sensitive data needs to be secured, but rolling out disk encryption to everyone in a company when a subset of everyone is dealing with sensitive info is maybe overkill, and the impacts to the primary activity of other depts needs to at least be quantified and considered.
Parent
People misunderstanding the question... (Score:5, Insightful)
The submitter is in a research institute. Some labs in that institute have patient data, and therefore require significant security like disk encryption.
His lab works with a protozoa, and has massive computational requirements. There will never be any patient data near his lab, because the people who work with patients are in a different lab (think different department in business). They do not need disk encryption.
You say Truecrypt has "1% overhead", PGP presumably has some other "% overhead." The submitter is asking what the details of that overhead for PGP, truecrypt etc are. Whats the CPU usage, memory usage? Are disk performance penalties constant, or are they dependent on average file size, number of files, format of those files, etc etc etc. "1% overhead" may hide whopping huge performance penalties for specialist users.
Parent
Re:People misunderstanding the question... (Score:5, Informative)
I can tell you that when we ran a PGP encrypted disk partition on a 12 disk raid 50 I had MAJOR performance losses compared to a standard raid 50. This was on older hardware, I had tested it on a 8 processor Xeon PIII 800 system with only 4 gig of ram installed, but it had a significant impact on data transfer rate.
and yes I like re-purposing the Killer SQL servers of yester-year into a "Holy CRAP THAT's YOUR NAS??!??!"
The hit was NOT on the drives, it was on the processors. It was enough of a hit to slow down data transfer rate out the GB connection to be as slow as a consumer single disk NAS.
Parent
Re:People misunderstanding the question... (Score:5, Insightful)
Run an analysis on the performance hit, document it, make a report and give the report to the persons who want the analysis done, and also the persons who pay the bills. (They might be different people).
The report has a summary that says: I must install this software to comply with policy. I will then be accomplishing my work at only X% of the speed I was before. If that is not ok, then I will need to spend $Y to upgrade the equipment in order to maintain the previous rate of work. End of story. If they deny the upgrades then... that's their decision. If they approve the upgrades - hey, new equipment!
The only potential problem I see is this: If the submitter has his own budget, IE he pays the bills, yet still must both maintain rate AND comply with the encryption policies... Hmmmm, well, not so easy. Then there needs to be a report that says his lab won't ever see patient data, with proof. Assuming the budget isn't there.
Parent
Re:People misunderstanding the question... (Score:5, Interesting)
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.
Parent
People misunderstanding words like 'require'. (Score:5, Insightful)
The submitter is in a research institute. Some labs in that institute have patient data, and therefore require significant security like disk encryption.
Repeat after me: "The first line of security is physical."
If the servers are locked in a room with limited access (like, oh, say, 95+% of servers in the corporate world), then the probably not.
Data security is about securing the data using reasonable compensating controls. If no one can get to the disks, and those who can comprise a limited list of, say, trusted sysadmins, then it doesn't matter whether they're encrypted or not.
Requirements, if properly written, never specify implementation details -- the means. They only specify what is needed. How that is achieved is irrelevant so long as it the requirement is achieved completely.
So other than for devices that are not in access-controlled environment (like laptops or, in some cases, workstations), the need for whole disk encryption at most places is nil.
Parent
Re:People misunderstanding the question... (Score:5, Informative)
I think the strategy should be to perform some speed comparison tests, to see if your research can be done with full disk crypto. Setup some vmware or other virtual machines.. and your test physical server.. Plug in a spare Hard drive, install a fresh OS, do testing of some virtual machines _with_ and without full disk encryption (on both host and on the VM), and tell them that the full disk encryption is slow if it is: reduces the effectiveness of disk cache, wastes memory, bogs down the CPU of machines that are needing to be used 100%, and better hardware is needed to run full disk encryption.
You're in research, and such a major change to your environment deserves to be looked at a little before you implement it...
I suspect with full disk crypto on your hardware backing the virtual disk, VM I/O performance will tank.
Show them nice graphs of research computing productivity on the same equipment WITHOUT full disk decryption, and WITH it.
Use "full disk encryption" policy as immediate justification for additional better hardware to compensate for the fact that the encryption is parasitic.
And note the migration costs and loss of research time that results in having to make such drastic changes.
Once you show the extra cost involved, they perhaps rethink the full-disk encryption blanket policy.
Just make sure the cost you show is high... (much higher than any imagined savings through simplified policy and assured security)
If you can't so much as justify a position against it, then why is PGP such a problem? If it doesn't hurt you... it certainly makes your research more secure from being stolen.
1% overhead is still a hit if you are using your equipment 100%.
But actually, I don't believe for a second that TrueCrypt or PGP is limited merely 1% overhead, the figure is deceptive in that running disk encryption has effects other than measurable disk I/O slowdown.
There is also CPU usage of the encryption, and memory and reduces page cache effectiveness.
i.e. The heavy cost of encryption must now in all likelihood be performed before data can be written to the page cache. This reduces system throughput.
You may measure simple operations as only impacted by 1%, but in reality, there are certain write patterns that this will hurt severely.
Just plain SELinux has overhead in excess of 10%.
I would expect full-disk encryption of 30% or higher.
It may be difficult to measure its true overhead if you don't fully use your hardware.
Parent
Re:People misunderstanding the question... (Score:5, Insightful)
Oh, so -you're- the type of network administrator who implements policies and software for the good of the network, software that's detrimental to the productivity of the people who the network is supposed to be good for, without consulting the users about their needs prior to the rollout?
I'm glad we met. Have you ever considered a career in sales?
Parent
Re:People misunderstanding the question... (Score:5, Interesting)
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.
Parent
Re:People misunderstanding the question... (Score:5, Insightful)
Have you ever worked for a medium to large company? This is the norm in such companies. Management doesn't care how much productivity was lost and of course, they still expect you to get your work done on time.
As well, just to correct you, its management enforcing recommendations from a security analyst. The network admin couldn't give a rat's ass, they just implement some of the policies. You forgot to mention unix/windows administrators, dba's, etc.. Share the hate. (BTW, i'm a DBA.)
Its the security analysts job to try and to prevent breaches, IT to implement and managements job to weight the cost of security with productivity. The problem is that management is too scared to set realistic security policies. All they care about is CYA.
Parent
Re:People misunderstanding the question... (Score:5, Insightful)
If you think that was sarcasm, head over to the ars forums and check the rabid response elicited when someone asks a question about plugging a switch into the drop in a conference room because multiple presenters need a wired connection.
Professional IT staff seem to get more bitter and hostile to the users daring to question their all-knowingness the more years in the industry they get. I'm glad I got out and into coding before I ever hit that level.
Parent
Re:People misunderstanding the question... (Score:5, Insightful)
Those would be the lazy bad admins and, unfortunately, are usually the only ones left after a period of time as the better ones all get better jobs/pay as soon as they can.
A good IT staffer knows their network and the various ways they can implement the policy's goals. (Note, policy should be abstract things like keep bad guys out of network, not specific things like install single Firewall Brand A and cut all other connections between network and internet.) They would also know how to accommodate changing needs.
Parent
Re:People misunderstanding the question... (Score:5, Insightful)
Fine, as long as you work my hours. I work in a job where I may be setting up at 0500 for a multi-person network-heavy presentation scheduled to go at 0630, and I have zero time for argument. I've had great support and lousy support, and yes, I bring my own network hardware in case the local admin doesn't have what I need.
That said, I almost never have a problem, because good network admins do indeed work with me, and lousy ones either (a) aren't there to complain, or (b) trust me far more than they should. Oh, and I ask (and explain and discuss and compromise) long before any equipment sees power. It's only polite.
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 (and if your own equipment is truly solid, which mine is).
Parent
Re:People misunderstanding the question... (Score:5, Informative)
Fine, as long as you work my hours. I work in a job where I may be setting up at 0500 for a multi-person network-heavy presentation scheduled to go at 0630, and I have zero time for argument.
Sounds like you may very well be the kind of user that makes IT staff bitter and hostile. If you didn't make arrangements with the IT staff for your presentation before your presentation is scheduled to start, how is that my problem? One thing that never fails to draw the ire of IT staff is a user who consistently doesn't tell anyone what they need until it's time to go live, then expects said IT staff to drop everything to accommodate their needs at the last minute.
I've had great support and lousy support, and yes, I bring my own network hardware in case the local admin doesn't have what I need.
That's reasonable. However, depending upon what you bring, the local admin may or may not be willing to plug your gear into his network. As the local admin, I am the guy that gets called on the carpet when rogue equipment takes down the network. If I don't know what the gear is or what it will do on my network, it doesn't get installed until it's been tested in a sandbox first. In the past, I've had rogue equipment cause routing loops which in turn caused spanning tree on my switch to turn off the port to the offending network drop, taking out most of a department (they had installed a SOHO switch because they needed more ports, but never told us). I've seen rogue equipment replying to DHCP requests causing conflicting IP addresses or IP addresses that were in an entirely different subnet than the main network. I could go on, but you get the picture. So please excuse me if I don't just take your word for it that your equipment won't break things, unless I know you and know that you really do know what you are talking about.
That said, I almost never have a problem, because good network admins do indeed work with me, and lousy ones either (a) aren't there to complain, or (b) trust me far more than they should.
As long as you are reasonable in your requests and are willing to compromise with the admins on your network, most admins, IMHO, will do their best to find a solution that both they and you can live with. From what I've seen, while the BOFH does indeed exist, he is more of an exception than the rule.
Oh, and I ask (and explain and discuss and compromise) long before any equipment sees power. It's only polite.
That goes a very long ways towards earning the trust of the local admin. I withdraw my first comment about how you sound like the type of user who causes IT staff to become bitter and hostile. I'll bend over backwards -- even at the last minute -- for someone who tries to work with me and/or has shown me that I can trust them.
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 (and if your own equipment is truly solid, which mine is).
There's the catch. While most people are reasonably intelligent, there are enough people who aren't to make network admins suspicious of others, if we don't know their technical competency. There are many users who think they know more about networking than the admins who built the network. Sometimes this is true, and sometimes it isn't. At my current job, there is a user that I trust very, very much. He held my job before I did, and still probably knows more about the network than I do (he left for a different department because he got fed up with the guy who used to manage the department). OTOH, there is another user who thinks he is God's gift to networking. While he does have a little knowledge...well, a little knowledge is a dangerous thing.
Parent
Re:People misunderstanding the question... (Score:5, Interesting)
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.
Parent
Re:Overhead (Score:5, Interesting)
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.
I work in a similar environment and we use truecrypt when transferring between labs and for data collection. For all other purposes we don't encrypt at all. What we do is keep medical information on a secure network but stored with with no personal identifiers, only a study id. The personal data as far as we need it is kept in a separate location on a machine that is not networked and is physically protected so that only the study admin team can use it (ie the same level of security as the paper records). The medical records and the personal identifiers do not usually need to be kept together for research purposes.
Parent
Re:Overhead (Score:5, Informative)
The patient information is a pretty serious concern. Any breach or loss of data covered under HIPAA, SOX, FERPA, or Privacy Act can result in some pretty severe expenses. The cost of notification to the individuals whose data was lost or exposed can run to more than $1,500 per individual, depending on the size of the breach. Base expenses start at $1-2M and go up fast. Litigation and fines can cost millions more. Anything that gets hacked or breached, that has information that should be protected, could put a company these days on the wrong side of the balance sheet.
Parent
Encryption is good for security, bad for performan (Score:5, Insightful)
Whole disk encryption is excellent for security, but it will bog you down in disk access times. Depends on a lot of things, but reading and writing files can slow down up to 50%, but usually the slow-down is much less. If you are doing something that involves a lot of disk access and it doesn't need to be encrypted, then create a special, non encrypted partition for that.
Re:Encryption is good for security, bad for perfor (Score:5, Informative)
The numbers on my machine are about 20% slower read and 30% slower write. I'm using 256 bit LUKS with serpent-xts-essiv:sha256.
Might I also suggest hardware encryption? Seagate (and others I believe) make drives that do AES128 (good enouhg for this sort of thing I believe) in hardware. Zero performance hit. No software required. Set a drive password and go.
Parent
Re:Encryption is good for security, bad for perfor (Score:5, Insightful)
I'm not sure that assuming that just because somethings done in hardware, that it happens in zero time (or even near zero time) is at all accurate. A review I read of a different encrypted drive, said it was 5-10% slower than it's non-encrypted equivalent. It wasn't the Seagate you're talking about, but I doubt that even hardware encryption can do it instantly, so I think your "zero" is an exaggeration.
Parent
Re:Encryption is good for security, bad for perfor (Score:5, Interesting)
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.
Parent
Re:Encryption is good for security, bad for perfor (Score:5, Informative)
Sorry, they "claim" that.
But on my core 2 2.4 Ghz machine, windows boottime more than doubled after encoding the system partition.
Yeah, i can get 100Mbyte/s linear reads and writes.
But for some reason, random or semi random access get hosed quite a bit.
Maybe it messes with the comand queueing, or the internal prefetch alorithmns, i dont know. Never had a problem on data partitions, but the performance impact on the system drive was enourmous (up to the point that even with 6Gbyte RAM, it wasnt fun anymore)
Ah, and i forgot one thing: the 100Mbyte/s is nearly 100% cpu load on both cores. I dont know where you get 1% overhead from... Even the in-memory benchmark only gets about 150Mbyte under full load on two cores.
S
Parent
Re:Encryption is good for security, bad for perfor (Score:5, Insightful)
It depends a lot on what you're doing with the data. If you've got a single-threaded process that's consuming 50MB/s and you can read 100MB/s from the disk and run 100MB/s decodes on the other core, you won't notice the speed difference. If you're doing random access then you will have, say, a 9ms seek time to get the data and then a few more ms to decompress it. If your process is already I/O bound (many scientific computing tasks are) then a 9ms decode per block will halve the speed of your computation.
The correct solution for this lab seems to be to borrow a policy from most defence-related sites. Have a secure and an insecure network. The secure network is allowed to access confidential data, the insecure network isn't. Run encryption on the machines on the insecure network, don't bother with it on the insecure machines. If one of the insecure machines is compromised or stolen then nothing confidential is lost.
Parent
Re:Encryption is good for security, bad for perfor (Score:4, Interesting)
Do you have any numbers to back this up?
Here's some numbers: http://ask.slashdot.org/comments.pl?sid=1012285&cid=25566509 [slashdot.org]
Make of them what you will :)
Parent
Re:Encryption is good for security, bad for perfor (Score:5, Informative)
That is interesting - if the overhead was really 1%, then why even bother with optimizations for multi cores?
The other thing I cannot understand is why anyone would want to run whole-disk encryption on a compute server. Even the US DoD machines that are used for classified research do not do this!
Parent
Re:Encryption is good for security, bad for perfor (Score:5, Insightful)
Linux software RAID 5 uses 2% CPU under heavy load.
Given the fact that you can always recover your data with any Linux livecd gives it a definite edge over a hardware raid solution where you need a similar model to read the data.
Parent
Re:Encryption is good for security, bad for perfor (Score:5, Insightful)
I have serious doubt we even need hardware RAID anymore with current CPU speeds.
At some point in time I believed the same thing. I did a test a few years ago to see if it's still worth it to bother with hardware RAID and configured an system with linux and software RAID.
This was for a fileserver in a high performance cluster so speed mattered. I don't have the exact figures here right now, but from what I remember two years ago the software RAID solution was between 7 and 15% slower. Once you start hitting the performance limit your processes hit I/O wait and your performance goes down. When I added LVM to that back then performance got shot to hell.
Now, it's not as bad as it seems, you still get decent performance (especially considering that your setup suddenly costs a lot less and can be done on commodity hardware), and with a fair bit of tinkering with blockdev and your read-ahead buffer (provided you have enough RAM, and your usage fits that particular pattern) you can still get some very nice performance.
The reason that we went with hardware RAID in the end was because hardware RAID isn't all that expensive, and the performance gains were noticeable especially on systems that have to run 24/7 at maximum throughput.
Again, for consumer systems and services where performance isn't a primary concern software RAID is an attractive option, especially if you're on a budget.
As for overhead with encryption: it would make a nice experiment but I think 1% overhead is very optimistic especially on a busy system. The only way to be sure is to compare your performance now to the performance when you encrypt the entire disk. The only time I tested truecrypt I got a throughput of 80MByte/s, while unencrypted I got 120MByte/s, and it's been a while since I tested this. Those truecrypt tests weren't finetuned either, it was basicly a test to see if it was easy to implement.
Anything I mention here has to be taken with a grain of salt since a lot of time has passed and a lot has changed since those tests.
If policy dictates that you have to setup X, the best way to become an exception to this policy is to prove that that policy is detrimental to your project and might end up costing a lot of money. Policy doesn't care about performance, but it cares greatly about money and lost time. Do your tests, do the math, add a pricetag and talk with your manager.
Parent
Policy fundamentalism (Score:4, Insightful)
Re:Policy fundamentalism (Score:5, Informative)
I'm with Smertrios on this one.. IT policy is just that.. a corporate policy. It's not subject to end-user interpretation, it's a definition of how IT resources are to be deployed and utilized. The written policy itself is what gives the company the "teeth" to discipline employees who choose to make their own interpretations and NOT comply.
Now back on topic: Whole disk encryption? For removable / transportable media, ABSOLUTELY! For enterprise data backups, ABSOLUTLEY! For live data on active servers, meh.. not as critical. If your data center employs appropriate physical, network and host security, your data is reasonably safe. If someone compromises your network -> system security, they've got your data.. encrypted or not. It's wonderful that your IT department has the desire to achieve the highest level of security possible, but there is always a balance that needs to be struck between the holy grail of ultimate security and the ability to do business. The OP needs to help everyone find that balance. A good place to start would be his local neighborhood HIPAA expert to make sure that no "business needs" prevent the company from maintaining regulatory compliance. Once the specific requirements for his continues compliance have been identified, then anything beyond that becomes somewhat negotiable.
Parent
Re:Policy fundamentalism (Score:5, Insightful)
Sounds to me like the IT department in question knows what it's doing, and who it's clients are. It's rarely mentioned outside an IT department, but I'll share one of the big secrets: 98% of the job of any IT department is to protect users from their own stupidity. The smartest users are the ones who realize this and give the IT department enough space to operate, while at the same time learning as much as they can about what they do so they have a real understanding of how to specifically follow the rules while at the same time getting everything done.
It's not impossible at all.
Parent
Here's a quick experiment (Score:5, Informative)
what are the disadvantages of PGP in terms of high-performance computational research?
O(1) ;)
Here's a brief experiment I ran: dd if=/dev/zero of=/home/jonas/zeroes bs=1048576 count=1024; that is, writing one gig of zeroes to a disk encrypted with ubuntu's disk encryption from the 8.04 alternative installer.
I saw a roughly constant ~30% CPU usage from kcryptd, going from 25% to 35%, on a 2.13GHz Pentium M (in a thinkpad t43p). So I have 1.5 GHz worth of cycles left.
Hard disk write speed was about 30 megs per second, but oscillating in big leaps. I did my observations with conky, sampling in one-second intervals, but conky is known to sometimes merge two samples. That's probably not the only factor, disk writes are most efficient when clumped together into one big (much preferably sequential) write, so I'd assume the kernel does this.
You haven't told us what your disk usage patterns are. But if you're doing one big read, one big computation, and then one big write, there's going to be zero impact (almost): there was lots of CPU capacity left.
Another low impact scenario is that you have a server that reads work units from disk, hand them to clients, gets results and writes the results back [I assume clients don't need any disk activity]. There you can read a bunch of work units in advance while the server is idle, then hand them out instantaneously when needed.
Aside: bugger, fault in my experiment: I didn't look at the CPU usage of kernel code that's not in the process table. Take what I say with a grain of salt.
But: do the measurement in your own world. My software, hardware and artificial measured usage pattern may differ from yours, subtly but enough that my conclusion doesn't transfer. Be scientific about it :)
Incompatible? (Score:4, Interesting)
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.
apply security if you really need it! (Score:5, Informative)
Positive:
- added security
Negative:
- worse performance
- you may forget the password (it has happened before.)
- has to be mounted manually (or at least type in password each time you need access to the data.)
- it's painful to backup
- it's painful to do a proper file systems check
- if the discs are somehow taken by the authorities you might have to give up your password (or be sentenced for whatever they think you have on the discs.)
- discs are only secure if they are not mounted.
There are a few negative sides, but usually they make up for the positive, i.e. if you really need the security then of course this is the way to go. Also remember to secure the other aspects of the machine, like physical access (including fire/theft), software protection (anti malware and virus) and network protection (firewalls, etc.)
Truecrypt does that and is better (Score:5, Informative)
This has happened (Score:4, Insightful)
I've worked with people during various research projects who decided to encrypt, for some very good reasons. I've had one admin die, and one researcher have a stroke. In both cases they had information necessary for the project that nobody else could get to, even when their hard drives were retrieved. The results are that after several years, the stuff is still sitting somewhere unusable because the people who attempted to get to it were stymied. Enforcing PGP on an entire network could multiply this problem. I would think that enforcing PGP on users not needing it would be a royal pain for them.
What we've done and thought of since:
Have only those with sensitive information encrypt. Have them work on machines not connected to the net. If they need net access, have them connect only for the time necessary, and mandate pre-encryption back ups prior to connecting.
Preferred, but resisted, keep the sensitive machines off the net and have the researchers connect to the net via a different machine without the sensitive info on it. If they want to use it for transfers of such info, make them use sneakernet between the sensitive and connected machines. In this scenario, they only need PGP for what they're going to transfer to the connected machine and thus to outside. Both admins and researchers expect full connectivity throughout their net, but the best security is a nackered line.
I use the sneakernet method exclusively. What I transfer when necessary is hundreds of MB to tens of GB of data. It takes me 10 to 30 minutes to encrypt, burn the data to DVDs and carry it to the connected machine. Like most researchers, I'm busy and don't want to spend my time doing this, but I have assistants I can put the task on.
Drive Errors? (Score:5, Insightful)
My concern with encrypting an entire disk would be fault tolerance. If a sector goes bad on a non-encrypted drive, you might lose a file. If it goes bad on an encrypted drive, do you risk losing more data or even the entire drive?
Of course, one could say that's why you make backups. But presumably the backups would also be using encryption. Therefore, they would be susceptible to the same effect. If there is a greater chance of total data loss on each device, the chance of multiple device failures leading to unrecoverable data also increases.
No that's not a problem (Score:5, Informative)
Read the FAQ [truecrypt.org]; drives usually have larger block sizes than the block size used for encryption, so there is not much difference.
Parent
Random Experiences with disk encryption (Score:5, Informative)
My workplace recently mandated that all laptops/portable media be encrypted. The impact to the system cpu usage isn't that significant to be honest, except when attempting to access, say, USB drives.
What's more important is the reliability of the disk itself.
As everyone knows, drivers shipped with laptops tend to be the first casualties of boot-sector-loading programs, like disk encryption and certain virus scanners.
Guess what happens when your encrypted disk can't be booted? You can't boot under a windows/emergency restore disk, because your partition is not readable. You can't boot off anything other than the hard drive. Guess what happens if the corruption doesn't allow you to run the encryption app's boot loader? Only solution is to format the disk.
Some of us who have been hit by this already have gone through the trouble of ensuring that any data we want to keep is stored on a shared drive, and that all work is done in a VM, which is occasionally uploaded to the shared drive as well. Since any given windows or driver-affecting update could kill our machine at any minute and make it entirely unrestorable, that's what's required.
So in essence, we're switching back to storing the media on a non-encrypted device because the loss of the data is more important than the security of the data.
This reminds me of the policies surrounding passwords I've seen at many companies; limiting the set of choices by making password creation requirements, and forcing them to change so often that people end up writing them down and leaving them on their desk. Defeats much of the purpose of having them in the first place.
Why are you writing to slashdot? (Score:5, Insightful)
In the time you spent writing this post to Slashdot, you could have written a friendly letter to your IT department stating that you want some machines to not use this encryption, because these machines need maximum performance and anyway do not store any kind of personal information.
Think about the purpose of Full Disk Encryption (Score:5, Insightful)
Encryption != Security (Score:5, Interesting)
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.
Re:Isolate sensitive data (Score:5, Informative)
You really want blanket encryption because you to worry about such things as swap space, scratch copies made and then deleted and people forgetting to encrypt files. /boot encrypted during install.
If the encryption is done at the block device level (such as dmcrypt on linux) the impact is minimal on how things work and overhead and you are fairly well protected (unless the machine is accessed while powered up by someone wants the data as opposed to just the machine).
Fedora can make all partitions except
Parent
Re:Isolate sensitive data (Score:5, Informative)
I second that.
If you're looking for an excuse not to protect the data, that's one thing. But TrueCrypt has lots of support and does a good job. PGP in general is well-known and has been refined frequently. That's the reason you don't find a lot of negative criticism-- there isn't any because it works fairly seemlessly. You'll find hard disk controllers don't help the process much, but if the machine does work in batches, and you backup frequently (presuming you're backing up an encrypted partition) and you use a UPS (or your controller supports battery-backed write cache), you can use various write cacheing driver options and techniques to boost performance dramatically. What write cacheing *can* do is to also cause transactional integrity problems if there's a machine hickup. Otherwise, writes are queued up and get batched onto disk. Performance can be 10x, so long as you understand the potential evils involved. It takes the sting out of the disk I/O degradation, but how much will vary with the duty cycles of your application's I/O profile.
Parent
Re:Isolate sensitive data (Score:5, Insightful)
Surely what is required is to isolate the sensitive information, so that it can be protected.
That's a great idea that in practice will leak your information. The reason is that _every_ application that touches your data needs to know that it should keep your data confidential.
Broswers know to not cache data transfered over https. It knows the data was encrypted, it knows to be smart with it [for "protective" value of smart].
When you have a program that reads a file through a transparent layer of encryption, it never sees the "please-be-careful-with-this" label, and so the desktop search engine will index all the strings, the editor will write backups to . or /tmp, and so forth. All the apps think they need to do is respect what you meant by your mode bits (if you're on *nix), so it'll chmod/umask the /tmp copy the right way. If someone grabs your disk and you didn't encrypt /tmp, you lose.
And no, encrypting /tmp won't fix it: you need to know that everything the user of the data can write to is encrypted if you want to be sure. I only know one way that I can somewhat confidently say solves the problem: encrypt everything. [and then there's the network, but we'll save that for another decade ;)]
Only encrypting the sensitive data is like carrying water in bucket used for target practice: stuff will leak.
Parent
Re:Isolate sensitive data (Score:4, Insightful)
Someone will write the passphrase down anyway. Isolate the data.
Parent
Re:Policy Exception (Score:5, Insightful)
If there really is a performance loss, and you can quantify it, then you can attack it from another angle, eg an impact statement to management along the lines of "This will introduce a %% performance loss to our workloads, at a cost of $$$. In order to maintain the same level of productivity we will require upgraded hardware at a cost of $$$".
Having a manager who is concerned about his departments budgets on your side can help your case too :)
Parent