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?"

Comments

Overhead

[Anonymous Coward]

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.

Re:Overhead

[stranger_to_himself]

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.

Re:Overhead

[emj]

Your solution is a good one, but one can nitpick on everything in security, I'm guessing the medical information probably have enough information in it too identify subjects. Web search logs usually help you to identify the user if you have enough data. (see AOL logs debacle).

Re:Overhead

[N Monkey]

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.

That's what we got told when our laptops were "whole disk encrypted" with a competing product.... but it now means that a windows hibernate and restore take of the order of several minutes(!) rather than 10s of seconds.**

I have not experienced PGP so maybe it has a much more efficient system, but I have my doubts.

**Yes I know that MS make it impossible for these systems (apart from their own 8-|) to guarantee security of the hibernate file but I can't see how that would affect the performance.

Re:Overhead

[wireloose]

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.

Re:Overhead

[morgan_greywolf]

I have not experienced PGP so maybe it has a much more efficient system, but I have my doubts.

You're right. No matter how you slice it, whole disk encryption will slow things down -- considerably. There's no getting around the CPU overhead that will exist on every disk block access -- reads and writes. Think about how many times a second the system accesses the disk. It's a lot. Even if you cache a bunch of stuff in an intelligent way (in which case you're trading system security for performance) you're still slowing things down because unless you have a hardware encryption board, encrypting and decrypting those streams must go to the CPU, unlike with unencrypted disk, where most of the reading is offloaded to the ATA/SCSI and DMA controllers.

Re:Overhead

[FictionPimp]

We have a policy that any computer that may contain student data must be encrypted if it regularly leaves campus. Prior to this I tested truecrypt full disk encryption on about 17 different notebooks of varying amounts of ram, disk speeds, and processor speeds. Even on the worst laptops we have (which are 7 or 8 years old), the performance was undetectable by any user we dropped in front of the laptop to use for the day.

I guess it just works differently for different people. My boss was very worried it would impact the end users (besides just typing in a password). After a long testing process we were hard pressed to come up with a reason not to just encrypt every notebook on campus. That is exactly what we did.

Now servers and desktops are another thing. We secure our network and we secure our locations (keycard access to offices, etc). Adding the overhead of encryption to our servers would just be a waste of resources at this point.

I'm just more worried about the CFO who walks around with all the data he thinks he might ever need on a flash stick being unencrypted than I am my oracle server that sits behind a a team of engineers constantly keeping it patched and monitoring it's access.

Re:Overhead

[N Monkey]

but it now means that a windows hibernate and restore take of the order of several minutes(!) rather than 10s of seconds.

Let me translate what you're trying to say: "WAAAH! WAAAH WAAAH WAAAH!", also, "WAAAH!".
Did I get that right? Full disk encryption of laptops is mandatory if you want to even pretend to have any semblance of data security. Deal with it, and deal with the CPU overhead. Maybe you could use the extra minutes(!!!!OHNOES!!!!) to get a head start on pulling your head out of your ass?

How mature. I'm surprised they have computers at your kindergarden.

FWIW, I 100% agree with the company's policy of encrypting the whole hard disk. I just don't agree with the claims of the software vendors that the overhead is unnoticeable.

Re:Overhead

[Anonymous Coward]

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.

So how does whole-disk encryption protect against getting hacked? If a hacker gets onto a system, whole-disk encryption is not going to stop them from seeing the data. Whole-disk encryption is only useful if the entire machine or drive gets stolen.

Re:Overhead

[DuckDodgers]

I use TrueCrypt to hide my financial data and pornography at home, and the performance is perfectly fine.

But we also run PostgreSQL database off of TrueCrypt encrypted disks at work, because we have laptops and workstations with patient data. PostgreSQL running on unencrypted drives is noticeably faster.

If this researcher really is running complex calculations, the difference could be crucial.

Re:Overhead

[Bobb Sledd]

And I might also point out that meeting the need of the requirements of encryption as defined in, say HIPAA, is also as simple as ROT13.

Just sayin'.

Re:Overhead

[starfishsystems]

This is a brilliant example of "defense in depth". You've taken the opportunity to understand the structure of the data and adapted the structure of your environment appropriately. Equally important, the solution, far from being exotic, is a prescription for how to treat aggregate patient data in general.

See how different this is from approaches such as indiscriminate encryption or application firewalling. In their place, these approaches may offer security value as well, but more along the lines of adding a layer of defense against the unforeseen. Their main advantage is simplicity, an important consideration when implementing a security policy such as "default deny" across the organization. But the data can't stay encrypted forever, and likely it has to pass between applications. Your approach addresses this case in a way that indiscriminate encryption cannot.

Re:Overhead

[bartwol]

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.

Though you effectively restate statute and assert the kind of theoretical costs that you would find in a consultancy white paper, your numbers are very exaggerated and divorced from statistically likely costs. They contribute little to the body of knowledge needed to perform the kind of practical risk analysis that is strikingly uncommon in security administrators and other people who make a living doing security. Of course, your points would be considered useful to an administrator who is more interested in the motions and rhetoric of compliance than actually advancing the interests of the populations that they are theoretically trying to protect. It would also be useful to any pitch-person in the business of security. Sheesh.

Re:Overhead

[stranger_to_himself]

Your solution is a good one, but one can nitpick on everything in security, I'm guessing the medical information probably have enough information in it too identify subjects. Web search logs usually help you to identify the user if you have enough data. (see AOL logs debacle).

Possibly, although at the moment we keep things like test scores and self-reported health and demographic information so it would be very hard to identify subjects. We are getting into whole genome analysis though, which researchers will need and will be potentially identifiable, so somebody is going to have to think very hard about that. Fortunately it's not my problem.

Re:Overhead

[Anonymous Coward]

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.

If it's hacked, what does a fully encrypted hard disk gain you? Nothing. About the main purpose for a fully encrypted hard disk is to deal with physical access, e.g. Laptop hard disks and the like. If the poster's employers workstations are world accessible, then fine encrypt, but if they've got concerns with security and think people might get access to the labs, then that's what they need to deal with because you can be sure there is more than just the workstations around that will have confidential data.

Re:Overhead

[hesaigo999ca]

I was about to suggest TrueCrypt...beat me to the punch!
Nice jab

Re:Overhead

[hesaigo999ca]

I agree, not everything needs to be encrypted, and there are ways of keeping data
separate from each other to avoid having to encrypt it.... an address a social security # or name are all worth nothing by themselves, and its a lot smaller overhead to encrypt the file that does the LINK between all of these then to encrypt all of it as one big file.

Re:Overhead

[Anonymous Coward]

Truecrypt Whole Disk Encryption has less than 1% over head.

I'll bet head is 100% better than some poxy disk encryption software, but whatever floats your boat I guess.

Encryption is good for security, bad for performan

[WK2]

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.

PGP expanding virtual disks?

[mlts]

Perhaps one answer for storing data securely, but allowing it to dynamic expand is to create a PGPDisk that is dynamically expanding. Then, the data in can be safe, but the file can be moved to bigger RAID arrays if need be.

Policy fundamentalism

[Pikiwedia.net]

An IT policy is a general rule which has to be interpreted and adopted. It's not supposed to be followed by the letter. Ask your IT department what they want to accomplish with the policy, and how you can help them accomplish that without having your work ruined.

Re:Policy fundamentalism

[Smertrios]

I hate to disagree, but I have to. IT policy is a law that must be followed. What the problem here is the people creating the law sees only the end goal and not the road that needs to be traveled. Talk to them and show them what is required of you during the research. Tell them that other ways need to be looked at in achieving the goal before this is implemented. More harm is done and time lost by people trying to circumvent the policies then it is by sitting down with them and stating the procedures that are done and stating why a different method is needed.

Re:Policy fundamentalism

[whoppo]

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.

Re:Policy fundamentalism

[yttrstein]

I'm in agreement with Smertrios as well. It's easy to see why such a blanketing policy is necessary--have you ever worked with scientists? While possibly quite brilliant, most of them seem to have the same problem remembering to keep sensitive data encrypted. The only logical solution to this is to write a policy which requires everything to be encrypted.

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.

Re:Policy fundamentalism

[CppDeveloper]

That may have been true prior to Sarbanes-Oxley and other legislation but in the "SarBox" world where Execs have to sign off on controls in place and Auditors audit that policies are complied with considering an IT Policy a flexible rule is likely to get someone quite upset at you.

Re:Policy fundamentalism

[Anonymous Coward]

...on genes from Tetrahymena, no humans here...

How could the data described be considered as PII? Is a potential hacker going to apply for a credit card with a gene?

Re:Policy fundamentalism

[vvaduva]

You are confusing policies with guidelines. Guidelines are often optional and serve as a "rule of thumb" or "best practices" for employees; policies are not. Policies (especially security policies) are, or should be established with the advice of legal counsel, and should be issued and enforced from an executive level.

If you don't want policies, do not issue them, otherwise you are just confusing employees and encouraging them to disregard issues which are important to the organization.

Re:Policy fundamentalism

[compro01]

Well, if you can get a credit card in my dog's name, it's not that big a leap. ;)

Re:Policy fundamentalism

[winwar]

"You are confusing policies with guidelines. Guidelines are often optional and serve as a "rule of thumb" or "best practices" for employees; policies are not. Policies (especially security policies) are, or should be established with the advice of legal counsel, and should be issued and enforced from an executive level."

Thank you. Thank you. And thank you again. Policies that are not enforced are worthless and as you stated, are detrimental.

If you don't want to have to discipline or fire someone for violating a policy, then don't have it.

You must not be in management :)

Isolate sensitive data

[sugarmotor]

Surely what is required is to isolate the sensitive information, so that it can be protected.

Blanket encryption may impress some people, but it hardly solves the problem.

Details of how to implement isolation and protection would depend on the data, and which subsets are used in the calculations.

Stephan

Re:Isolate sensitive data

[Anonymous Coward]

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.
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 /boot encrypted during install.

Re:Isolate sensitive data

[jonaskoelker]

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.

Re:Isolate sensitive data

[calmofthestorm]

Someone will write the passphrase down anyway. Isolate the data.

Re:Isolate sensitive data

[postbigbang]

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.

Re:Isolate sensitive data

[Anonymous Coward]

Surely what is required is to isolate the sensitive information, so that it can be protected.

Blanket encryption may impress some people, but it hardly solves the problem.

From what I've heard on slashdot, whole disk encryption solves the following problems:
1. No risk of protected data being stored unprotected in, for example, page files or temp files.
2. No risk of users unknowingly saving data outside of protected areas.
3. No risk of applications storing data outside of protected areas by default (e.g. saved login credentials, data to 'work offline' from network servers).

Of course, this sort of protection is more common for laptops than for workstations, and in the specific case being discussed it would only be sensible for the local IT people to set up the high performance computing researchers with an unencrypted disk or partition to store their data on.

Re:Isolate sensitive data

[pythonhacker]

I completely agree with this. Blanket encryption is akin to wearing full body armour because you are afraid of mosquito bites.

Isolate sensitive data and keep them in separate partitions or folders. Linux offers partition encryptions so, you can put all your sensitive data in say /home partition and encrypt it. Software full disk encryption programs are heavy and are not the solution to securing sensitive personal data.

Re:Isolate sensitive data

[samjam]

The mosquito only needs one patch of skin to spring a leak. Full body armour stops that.

If you don't wear full body armour, expect a leak

Re:Isolate sensitive data

[mdielmann]

Surely what is required is to isolate the sensitive information, so that it can be protected.

Only encrypting the sensitive data is like carrying water in bucket used for target practice: stuff will leak.

He said isolate, not encrypt. It changes the context a bit, doesn't it?

Re:Isolate sensitive data

[Karellen]

I agree. I do things the other way around, and have almost everything encrypted.

I then have a unencrypted disk mounted at /mnt/unencrypted/ with per-user subdirectories (usually symlinked from ~/unencrypted for each user) which can be used for data - usually large files - that are known to be non-sensitive.

Everything users work on is protected by default. Users need to make a conscious decision to put stuff in the unencrypted partition, so they tend to only do it after they've noticed a performance problem, and thought through whether it belongs on an unencrypted disk.

Re:Isolate sensitive data

[FictionPimp]

Lime disease. Nuff said.

Re:Isolate sensitive data

[Anonymous Coward]

Hell yeah, Fedora rocks!

Re:Isolate sensitive data

[kevingolding2001]

If you don't wear full body armour, expect a leak

On the contrary, I usually find the urge to take a leak only occurs just after the full body armour has been put on.

Re:Isolate sensitive data

[cryptoguy]

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.

It all depends on what you are protecting and how that information is used. In the most demanding case, you need mandatory access controls (something like SELinux, data classification, no read-up, no write-down...). If that is your situation then getting a policy waiver will be dramatically harder. You might be able to get a waiver if you airgap your machine from the sensitive network, etc. If your business is not sensitive enough to require mandatory access controls, then you have a better shot, if you don't handle sensitive data on the machine you want exempted.

Re:Isolate sensitive data

[Anonymous Coward]

Only encrypting the sensitive data is like carrying water in bucket used for target practice: stuff will leak.

Yes, that's why he said isolate.

Example- you have a research lab. All the equipment in the lab is NOT connected to any outside network, period. The only people allowed in the lab have access to the data anyhow, just password protect the terminals.
Now, once you need to store the data for backup, or access it outside the lab, then is when you encrypt the data.

Re:Isolate sensitive data

[Anonymous Coward]

Only encrypting the sensitive data is like carrying water in bucket used for target practice: stuff will leak.

This is the best post here.

You cannot rely on your users to determine what is sensitive and what is not. You basically have to treat all of your data as "sensitive" and therefore encrypt any and everything. Can you truly encrypt everything? No, but it's certainly a goal to shoot for. To use an analogy here think of safety. All companies shoot for 100% safety. Factory floors all have a sign up detailing their "X days since an accident." Is 100% safety possible? No, but that doesn't mean you stop striving for it.

Upper management will not care about performance hits. They WILL care when the next article runs in InformationWeek or the WSJ detailing that XYZ public company had a laptop (or tape, or whatever else) stolen that wasn't encrypted.

Re:Isolate sensitive data

[Anonymous Coward]

I wouldn't exactly say TrueCrypt has lots of support. It is a good product with a lot of great features; I'm not putting it down. However they take their forums down for months at a time, do not provide a method for paid support, and problems often go unfixed when reported via the problem submission or on the forums. Support is not a strong point for TrueCrypt.

Full hard drive encryption is useful if users are able to store data on their local machine, and there is a reasonable chance that the physical machine could be stolen. Break-ins happen all the time. Storing data locally is not desirable but is sometimes unavoidable. Encrypting the hard drive makes it unlikely someone will be able to inspect the contents of any local files.

Re:Isolate sensitive data

[postbigbang]

If you ask me, and no one is, TrueCrypt is an excellent candidate for a business plan. My implementations have been clean and not scary at all, but I will admit to them being 1) small and 2) script-automated [my own].

Re:Isolate sensitive data

[jonaskoelker]

He also said protect. I don't think he was talking about radiation suits ;)

Re:Isolate sensitive data

[harlows_monkeys]

You make a decent argument for blanket encryption on machines that have sensitive data.

HOWEVER, an effort should be made to limit the machines that have sensitive data in the first place. A policy of "fully encrypt every machine in the place" will lead to complacence. People will think of every machine as a safe place to store the sensitive data, and soon the sensitive data will be all over the place.

Policy Exception

[Anonymous Coward]

You've got a good case for an exception from this policy. Just follow the exceptions process and have your management sign off on the risk. Case closed.

Re:Policy Exception

[jamesh]

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 :)

Re:Policy Exception

[Peter (Professor) Fo]

Explain your concerns to the IT bod. If they say it will be fine and it isn't then it's their problem to fix. Check that they have a backing-out scheme first.

Re:Encryption is good for security, bad for perfor

[QuantumG]

Do you have any numbers to back this up or are you just repeating common knowledge from decades ago?

TrueCrypt claim a 1% overhead. With multi-processor machines, I doubt that's even accurate anymore.

Disk&CPU

[MortenMW]

It will take longer time to read/write and the CPU will also take a hit.

Here's a quick experiment

[jonaskoelker]

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 :)

Re:Here's a quick experiment

[LiSrt]

"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 :)"

Best advice I've seen - try and build up a representative sample of a day's work (or just a random sample if that's not easily determinable), copy it, run one copy on unencrypted disks and one on the mandated encryption.

If there's a significant difference take the evidence to your IT dept. or supervisor and hope for a favourable decision.

Re:Here's a quick experiment

[Splab]

"There is lots of cpu cycles left"
Uhm. You are losing 30% cpu cycles, that is quite a lot. Yes there is amble power left for your office apps etc. but original poster says he is doing high performance computing - losing 30% of your throughput for reading data is a lot!

Re:Here's a quick experiment

[emj]

You can get a dump of usage pretty smply now days (echo 1> /proc/sys/vm/block_dump), but it's going to be slow logging via syslogd to local disk. And you only get reads from files not dirs.

Or you can use blktrace haven't done that myself.

Re:Here's a quick experiment

[backwardMechanic]

Are you sure your gig of zeros are treated exactly like any other data? If I screw up my simulations they usuually end up processing lots of zeros. It's obvious when this happens because they finish very quickly. Maybe you should generate a gig of random numbers instead?

Re:Here's a quick experiment

[TranceThrust]

It's not just 'a lot', it's unacceptable. HPC usually is about real-time performance or doing huge jobs as fast as possible. In the latter case; imagine waiting 3 years instead of 2 for a calculation to finish. Regarding real-time work, 30% cpu loss may very well be the difference between possible and impossible.

Re:Here's a quick experiment

[Anonymous Coward]

Here's my experiment. First, I use dd to write a 512MB file of zeros to an unencrypted partition, and to an encrypted partition using loopaes with aes-256.

viperfish:/home/nick# time dd if=/dev/zero of=/test.zero bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 1.17828 seconds, 456 MB/s

real 0m1.180s
user 0m0.000s
sys 0m1.164s

viperfish:/home/nick# time dd if=/dev/zero of=/home/nick/test.zero bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 1.34818 seconds, 398 MB/s

real 0m1.350s
user 0m0.004s
sys 0m1.104s

Next, I try shredding these files:

viperfish:/home/nick# time shred -u /test.zero

real 4m45.000s
user 0m2.024s
sys 0m17.485s
viperfish:/home/nick# time shred -u /home/nick/test.zero

real 7m20.984s
user 0m1.924s
sys 0m23.369s
viperfish:/home/nick#

For writing 512 MB once, I saw a difference of 456MB/s versus 398MB/s. For shredding, I saw a difference of 1.8842MB/s vs 1.218MB/s. Big difference.

Re:Here's a quick experiment

[MikeBabcock]

Performance for disk encryption is a fixed number, not a ratio. 30% of the gp's cycles may well work out to 3% of the questioner's cycles. The number of cycles required to do the encryption is pretty constant, plus or minus the CPU in question and the disk throughput of course.

Re:Here's a quick experiment

[jonaskoelker]

Maybe you should generate a gig of random numbers instead?

It would either take time to run the PRNG, or time to wait for the true RNG. That has huge potential to produce results that will mislead the unwary interpreter.

Re:Here's a quick experiment

[jonaskoelker]

losing 30% of your throughput for reading data is a lot!

How do you conclude that this loss happened? Nit: I wrote, not read.

The disk has one maximum write speed (n MB/s). The cpu has a maximum write speed (m MB/s) in terms of how much encryption it can do.

If m is greater than n, you lose 0% I/O speed, at the cost of computational resources. What the impact of that loss of CPU speed means depends very much on the application.

If the computation doesn't do any I/O while it's happening, you lose 0% of your computational resources at the cost of a some I/O delay [if you read+decrypt all data before starting the computation].

If the CPU is spent at a big server in the middle that distributes work units and needs the CPU for exactly nothing else, and can keep up with the clients, it's a 0% real-world loss of throughput.

[some of these models are bogus]

If you start interleaving I/O and computation, things get a lot more hairy. And my scenario is probably not very representative. That's why I suggested that the questioner did an experiment of their own: then they'd know that in their particular application, the impact is going to be within some parameters they do know.

And for academic purposes: so the CPU and disk have upper throughput bounds of n and m MB/s. What I probably should have done is encrypt some zeroes and store them in /dev/null to measure the CPU alone. Then, on the unencrypted boot-strapping partition, do a big write to measure unencrypted write performance. Then do both, and compare all the numbers.

Re:Here's a quick experiment

[backwardMechanic]

Pre-generate the numbers?

From experience

[Anonymous Coward]

It took 2 days to encrypt an entire 160gb ide hard disk with a K6-2 400mhz processor, and afterwards the computer could only server files at about 400k per second. With a 2ghz processor the performance difference is negligible, and could serve at full speed with only tiny cpu usage. So I think full disk encryption overheads is irrelevant on modern cpus.

As for not being able to resize a partition, well that's good because if your hard disk is to contain anything of importance then you would have to be inept to resize partitions and expect data to maintain it's integrity, no matter what the file system format or brochures on partitioning programs try to tell you.

Re:From experience

[Anonymous Coward]

As for not being able to resize a partition, well that's good because if your hard disk is to contain anything of importance then you would have to be inept to resize partitions and expect data to maintain it's integrity, no matter what the file system format or brochures on partitioning programs try to tell you.

Off topic, but any filesystem that does not support (at the very least) online growth has no place on any system of importance. I am looking at you Microsoft, not letting us resize C: drives easily.

Re:From experience

[Anonymous Coward]

I still don't trust partition growing. Even if you can recreate allocation tables that are entirely consistent with the new size. There is still no guarantee that installed software or system services aren't remembering the partition size and have somehow locked to a constant partition. In the case of Windows I'm thinking services like swap files, hybernate files, disk caching, ready boost, DLL cacheing, file compression / encryption etc... How could a partition reallocation algorithm guarantee that these sub systems aren't broken by the change?

Re:From experience

[Alpha Whisky]

How could it possibly be in Microsoft's interest to allow or facilitate the resizing of partitions?

They want your hard drive to be one big C: NTFS partition with no room for a Linux partition.

If you run defrag on a fairly empty NTFS partition it's noticeable that some data will get shoved to the end of the partition and probably won't get moved back to the beginning.

If I were to be unkind, I would suggest that this is deliberate behaviour to prevent third party partition resizing applications reclaiming enough space to make a partition for a competing operating system install.

Re:From experience

[Anonymous Coward]

That's what filesystems were invented for some time ago. Srsly. No program will access its data the way you describe.

As long as you don't create/remove partitions to change the partition order, it'll keep working. Other than that you'll have your backup when things go wrong. Because things can go wrong, if there's a power outage in the middle of the process of moving your data around, it'll be screwed.

If you don't know, don't be paranoid, just ask someone who does.

Re:From experience

[Anonymous Coward]

How could it possibly be in Microsoft's interest to allow or facilitate the resizing of partitions?

Err... I guess you're not aware that Vista has a built-in partition resizing tool. I used recently it on a new Dell 530 to shrink the Vista partition from 500Gb to 50Gb before installing Ubuntu** and it worked just fine.

** Yes, I'm aware that I could have bought a 530n with Ubuntu pre-installed, but at that time the particular discounts available meant that I got a better spec machine with Vista than I would have for the same price with Ubuntu.

Re:From experience

[RMH101]

How often do you have to change a partition size, anyway? Enough that it's a reason to avoid encryption? For the odd time you need this, decrypt, resize, and re-encrypt...I can't see why your average research scientist would *want* to mess with repartioning his laptop.

Re:From experience

[Anonymous Coward]

Indeed, thankfully my entire exposure to Vista so far has consisted of creating Vista restore DVDs for a friend and then replacing it with XP on his new laptop. I have no immediate plans to stop using XP as most of the applications I need to use only run on XP.

Re:From experience

[Solra Bizna]

If you run defrag on a fairly empty NTFS partition it's noticeable that some data will get shoved to the end of the partition and probably won't get moved back to the beginning.

If I were to be unkind, I would suggest that this is deliberate behaviour to prevent third party partition resizing applications reclaiming enough space to make a partition for a competing operating system install.

Accesses on a hard drive are theoretically faster closer to the edge of a platter.

-:sigma.SB

Re:Encryption is good for security, bad for perfor

[msormune]

True. I have serious doubt we even need hardware RAID anymore with current CPU speeds. A few % overhead does not seem much.

Problems

[jcookeman]

I know we've had significant problems trying to roll out whole-disk encryption. Unless it's necessary, I'd say stay away from it. Of course, for sensitive information and travelling, it's almost a necessary evil these days.

feel-good actions

[scientus]

in these type of departments all the computer are on all the time anyways and whole-disk encryption is 100% vulnerable to hard-boot attacks. It may be remotely useful on laptops but for desktops its entirely useless

if you want to actually protect your data you need to encrypt only whats sensitive and only mont it when neccicary. also PGP is closed source and what are you going to do if they stop supporting, use truecrypt or LVM, etc. Also dont neglect network protection where the real data is stolen

Good question!

[Ceriel Nosforit]

Good question! It's nice to see something of this caliber on Ask /. for a change.

I have no clue what the answer is, though.

Encrypt only what's needed

[Errtu76]

Put sensitive data on a seperate partition and encrypt that, together with your swap drive. Problem solved. Leave everything else unencrypted.

Re:Encrypt only what's needed

[Jellybob]

As other people have said already, if you do it that way then you have a risk of data leaking to unencrypted areas of the disk - the files might end up getting written to swap, or copied to /tmp, at which point your encryption is useless.

Re:Encrypt only what's needed

[Errtu76]

That's why i said to also encrypt your swap. But i missed the /tmp partition. Files can't just 'leak' to another partition if you configure your applications correctly.

Re:Encrypt only what's needed

[compro01]

which is why he said to encrypt swap.

Incompatible?

[Bromskloss]

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.

Re:Incompatible?

[calmofthestorm]

Well it's true that encrypted data can't be compressed. That's why you encrypt the compressed data.

Re:Incompatible?

[Anonymous Coward]

The way I interpreted this is that when you have binary blobs of compressed data which are all generated in a similar way it can be easier to deduce a private key when you have a better idea of what is underneath the encryption layer. Once a pattern is detected your encryption is hosed.

Compression?

[91degrees]

"Furthermore, there is some evidence that certain forms of compression are also incompatible with PGP whole disk encryption."

Well, you won't be able to get much compression if you try to compress the PGP encrypted disk, but surely you can encrypt all compressed files since they're still just data.

Re:Encryption is good for security, bad for perfor

[imsabbel]

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

Re:Encryption is good for security, bad for perfor

[jonaskoelker]

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 :)

What are you trying to prevent?

[Nicolas MONNET]

Their product doesn't seem to run on Linux.
There is better, cheaper F/OSS software to do the same thing though; Ubuntu and FC9 already include a whole disk encryption option at install. (It's better because it's much less likely to have an NSA back door, although obviously never completely certain).
As for performance, when I tried it (luks encryption) on a desktop machine, it wasn't noticeable; but I wasn't moving hundreds of gigs around.
The question now is what are they trying to protect. Encrypting laptops is sensible, and in fact, given how easy & cheap it now is, it's rather stupid not to do it. On desktop PCs, it's not that clear. Whole disk encryption will only protect you against someone with physical access to the machine turned off. It certainly won't protect you against trojans or browser based vulnerabilities. So the question is, do random strangers roam your offices?
And encrypting servers/clusters? That's just silly; unless you expect the men in black to storm in your building.

Re:What are you trying to prevent?

[kefa]

Whole disk encryption will only protect you against someone with physical access to the machine turned off.

Surely encryption can also protect you on a running machine with the screen locked and autorun disabled (so long as your password is good enough).

Re:What are you trying to prevent?

[Growlor]

In theory, no. If there is a "bad guy" who wants your data and snags your laptop which is powered-on with a screen saver lock running, then all he has to do is keep it powered-on and try to either attack the OS (such as the recent Windows vulnerability that allowed unauthenticated remote admin) or use something like the Firewire DMA capability (or maybe even use the PCMCIA cardbus adapter on a laptop) to pull data directly from memory.

Re:What are you trying to prevent?

[Growlor]

Using FDE (Full Disk Encryption) on desktops or even laptops can be useful for preventing embarrasment when a janitor or other after-hours employee steals a desktop and sells it for parts (maybe on E-bay.) You then don't have to worry about headlines about your employer allowing all its employee's SSN's or customer CC #'s to be lost.

Re:What are you trying to prevent?

[Lupu]

You seem to be forgetting one very important aspect: hardware failure.

Harddisks fail. I've had several disks fail while under warranty, and I wouldn't be sending them in for replacement if the data on the disk wasn't encrypted. Consider a NAS with several disks in a RAID array -- replacing faulty disks isn't all that uncommon, let alone within the five year period that some manufacturers provide warranty for.

Re:What are you trying to prevent?

[Growlor]

Oops, meant to say "desktops or even servers" and not "desktops or even laptops" - sorry. Admittedly, servers may be a bad idea in some cases, but servers is a pretty broad term and can mean anything from a machine locked up in a Fort Knox like hosting environment to a PC in a broom closet at someone's office in eastern Europe!

Re:What are you trying to prevent?

[Sir_Lewk]

Just FYI, Fedora dropped the "Core" a few versions back. It's just Fedora 9 or F9 now. (although packages still have a *.fc9.*... in them...)

apply security if you really need it!

[ekran]

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.)

Re:apply security if you really need it!

[Bert64]

It's not uncommon to see an organisation that has no real clue, and have been sold a "full disk encryption" scheme which doesn't require a password while booting...
That is, the key for the encryption is stored somewhere on the disk, possibly obfuscated, so you can boot up the disk in a VM with a debugger attached to retrieve the key, or you can use that same debugger to bypass the login process once the machine has booted etc...

Re:apply security if you really need it!

[NeoSkandranon]

Would this be the case in a system where the encryption software seems to do something (brief loading/splash screen) just before windows boots?

In the implementation I saw like that, I assumed that the windows logon was the "password"

Re:apply security if you really need it!

[muckracer]

> Positive:
> - added security

True. It's a Good Thing in this day and age, when all kinds of people assume they have a special "right" to see *your* data and activity.

> Negative:
> - worse performance

Negligible on modern hardware. Hell, I used encrypted partitions already on a Pentium 1 with no major slowdown.

> - you may forget the password (it has happened before.)

True. That's why IMHO passwords/-phrases *should* be written down (though not on the legendary Post-It :-)). Be creative.

> - has to be mounted manually (or at least type in password each time you need access to the data.)

A keyfile, for example on a USB stick, is a password-less/convenient option.

> - it's painful to backup

No, it's the same as any other drive, assuming it's mounted.

> - it's painful to do a proper file systems check

No, it's the same as any other partition once mounted.

> - 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.)

You could be held in contempt of court if ordered to produce the key/passphrase...true. Your decision though. Depends on the situation/country/amount of voltage on your genitals with a definite YMMV. Research that prior to implementation.

> - discs are only secure if they are not mounted.

True, but they aren't any less secure than unencrypted either.

Re:apply security if you really need it!

[Anonymous Coward]

You've obviously never used PGP Whole Disk.

Re:apply security if you really need it!

[Bert64]

Well, that's hardly secure, since it has to decrypt all of the windows files and boot the OS... And for that, it must have a static key stored on the machine in plaintext or easily reversible encryption, or keep all of the system files unencrypted.

Re:apply security if you really need it!

[david_thornley]

Another negative: it's easier to lose the whole disk. On one assignment, I was issued a laptop with full-disk encryption. One night, during a software download, something went wrong, and it wouldn't boot up into Windows. This meant there was no way to retrieve any of the data. This being a financial institution, they couldn't just wipe the disk, so as far as I know it's still in storage somewhere. Fortunately, there was nothing on the laptop that anybody missed, but IT spent a lot of time trying to figure out what to do with it.

Disk Encryption

[mseeger]

Hi,

we're selling a different solution, but some remarks from our real life experiences:

• Performance is not the problem. Compared to other problems, this one is insignificant. It gets even more insignificant with multi core CPUs.
• Encryption is also not the problem, it's the decryption that gives you headaches. Users loose passwords, tokens, certificates, etc... You must be able to help them when they are somewhere in Africa and need to recover their lost password for the disk encryption.
• Encrypted disks are significantly harder to recover from a head crash or other HW related problems. Try the procedures your manuacturer gives you at least once before you need them...
• There are a lot of other issues to consider:
  • You need to check the compatability with your disk encryption with each new OS release and new hardware. As for all enterprise projects: try to use as little different hardware/software as possible.
  • Service and Helpdesk personel needs to be trained
  • Think about how to do the rollout
  • Do people with encrypted notebooks travel to countries where it might be illegel?
  • How do you handle requests from law enforcement if they suspect one of your users?
• General rule: Every hour you put into the project before the rollout saves you 10 hours support :-)

Sincerely yours, Martin

Re:Disk Encryption

[Saunalainen]

General rule: Every hour you put into the project before the rollout saves you 10 hours support :-)

1. Increase engineers's salaries to more than 10 times those of helpdesk monkeys

2. Spend no time at all on rollout

3. PROFIT!

Re:Disk Encryption

[TheRaven64]

Performance is not the problem. Compared to other problems, this one is insignificant. It gets even more insignificant with multi core CPUs.

I'm sorry, but this is just wrong. Encryption, with a sufficiently fast CPU, will not affect your throughput. It will, however, affect your latency. I know, from the results of part of my PhD, that in an I/O bound scientific computation process, a 0.5% decrease in average latency can give around a 20% better running time. If decrypting a block takes 1ms, added to the 9ms for seeking, then you can easily be slowing down the kind of task that the original poster is talking about by 50% or more.

Most users won't notice encryption because most users don't do much that's I/O limited, and when they do it's often limited by throughput, not latency. Try running full-disk encryption on your database server, or on a scientific computing machine, and you will see serious performance problems.

Re:Disk Encryption

[mseeger]

Hi,

generally speaking: Performance is not the problem. Most user use: Word, Excel, Exchange, Solitaire, Minefield, .... Your case affects less than 1% of all users :-) I know, it's not much of a consolation....

Usually you encrypt the laptops of your travelling personel. Encrypting the scientific workstation or the database server is usually not recommended even by the manufacturer of the software.

Sincerely yours, Martin

Re:Disk Encryption

[multipartmixed]

...which comes right back to TFQ: the submitter is running a high-performance scientific workstation.

Personally, I think he should put through a budget request for the most expensive computer he can find and say he needs it to keep working at his current pace after WDE is installed.

Communicate.

[elh_inny]

Don't go against the grain entirely, only encrypt partitions and folders where user data and profiles are stored.
Get in touch with the policy makers that you want an exception clause in the policy for research/lab computers.
I'm sure can email, call or talk to someone. Get some allies on that, get involved with the politics a little and youll save yourself trouble later on.

I'd probably even suggest to those policy makers not applying the FDE policy to stationary computers at all.
After all, if it's in the office, physical security should suffice to prevent someone from the outside accessing.
And if it's a disgruntled/bored employee, heshe will have passwords anyway, so FDE won't do much in such case.

Bothered about Windows 95 compatability?

[Anonymous Coward]

You cited an extremely brief review about a 1.0 product on Windows 95 as evidence that 'there might be problems resizing a partition'?

Whole disk encryption or an encrypted volume should be mandatory for your confidential data on a laptop. For windows, use PGP, it's fine, or use truecrypt, which is fine also.

For linux, use a dm-crypt volume or (again) truecrypt if you care about moving your data to windows - you'll be within the spirit of the security policy and won't notice the difference.

You're wasting your time, however, putting disk encryption on a server thats in a locked computer room or data centre - no one will be around to decrypt the volume after a reboot or crash, or you'll sticky tape the passphrase to the machine, so if it's stolen you are still hosed.

Don't leave servers in public areas though!

Depends

[omb]

Having just spent about 18 months working with highly clustered HPC the answer is your milage will vary. On your own laptop, even dual core,
this is a silly idea, encrypt just what you must and de-/en- crypt it once as part of the JOB; no on the fly especially if your problem uses n000 giga-bytes of data; in an RDB encrypt just the appropriate column. E.G. if, for patient data you encrypt the Name/Address ... you have (a) anonimised the entire data-set and you probably have (b) zero processing cost.

En/De- crypting cell data for the Gas or Elasticity equation or the intermediate results of a stochastic process is a waste of time.

If you are into heavy-metal c 1000 Barcelona level cores, then your storage architecture may/will be doing its own thing and that may encrypt everything but with such an architecture that will be done in the DISK CONTROLLER not the application CPUs.

The point is (a) if you travel, or (b) you have some sensitive data on a mobile device _DO_ encrypt it --- it will save you and your organization from much cost and _egg_on_face_.

Repeat after me

[MosesJones]

"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.

Re:Repeat after me

[Anonymous Coward]

I've always been curious about determining the exact impact of using TrueCrypt full disk encryption, but I've never cared enough to seek out the tools necessary to perform the tests, and at least in everyday usage I've never noticed a performance hit (Intel Core2 Duo w/ 2GB RAM running XP, so it could simply be my system is fast enough that I don't notice it, but on a slower/older system it'd be more noticeable). Since you're suggesting there is a significant hit and that GP should run some real tests, do you have any in mind? I'd love to know for certain how it's impacted my systems.

Re:Repeat after me

[Anonymous Coward]

"Marketing is not a science even if its an Open Source project"

Re:Repeat after me

[morgan_greywolf]

"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.

Re:Repeat after me

[Trails]

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.

Re:Repeat after me

[Anonymous Coward]

Repeat after me

morgan_greywolf was modded down, just for following orders.

Cue the Godwin in 3... 2... 1...

Re:Repeat after me

[duffbeer703]

The alternate solution will likely be worse than whatever disadvantages the FDE solution presents. You have a legal responsibility to safeguard critical data, and alternatives are probably worse.

To meet the audit requirements where I work, all of your work that involved PPSI would need to take place on a secured server via a terminal connection.

Re:Repeat after me

[Golddess]

Hmm, I was apparently logged off at home and didn't realize it.

I'm still curious to know the exact impact, if you could kindly provide a direction for finding some good tools to perform exact tests.

Re:Repeat after me

[Anonymous Coward]

Marketing is a succulent, open faced potroast sandwich.

Re:Repeat after me

[Anonymous Coward]

Yeah, well... "following orders" didn't work for those on trial in... ohhhh... I see what you did there.

Re:Repeat after me

[Captain Splendid]

Marketing is a succulent, open faced potroast sandwich.

Well, that sounds fabulous! I'll buy that for a dollar!

Re:Repeat after me

[Trails]

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.

Re:Repeat after me

[xappax]

Yeah, because everyone knows that when one person in a company is handling sensitive info, it always stays with that person and that person alone.

Re:Repeat after me

[lionchild]

After you have done your analysis as to how much productivity is lost, be -certain- to equate that to a dollar figure, so it can be extrapolated over the quarter and over the year. Nothing will make or break a project more than being able to assign a hard-dollar figure to it.

If it takes you an additional hour a week to preform tasks, and your value is $100/hour, then you effectively cost an additional $5,200 a year for lost productivity. Multiply that times all users in your lab. Managers understand cost and budget impact more than passionate resistance.

Good luck!

Re:Repeat after me

[DragonWriter]

Yeah, because everyone knows that when one person in a company is handling sensitive info, it always stays with that person and that person alone.

If, as was stated to be the case here, the reason data is "sensitive data" is because it is "sensitive patient info" (i.e., HIPAA PHI), the same legal requirement that produces the obligation to safeguard the data with technical means also produces an obligation to prevent any access by anyone who doesn't have a specific need to have direct access to the patient data (and, at that, the specific bits of sensitive data they have contact with.) So, if only a certain definable subset of the organization has any business need to access sensitive patient data (which has been clearly stated to tbe the case here), the organization has a positive legal obligation to assure that only that subset of the organization ever has contact with that data.

Re:Repeat after me

[Heather D]

Agreed, I remember the people at the school that I worked at in the early 90's coming up with the bright idea to save money on storage by running our database off of a doublespace compressed disk. Update time on anything more than trivial edits went through the stratosphere as the thing did not have the cpu needed to handle the load. This, of course would cost considerably more than the larger drive would.

Re:Repeat after me

[Anonymous Coward]

]IT is enforcing an overly broad solution on
]everyone, with considering the downside.

Well what's the problem then?

Re:Repeat after me

[neonKow]

So the best solution is to encrypt every drive on the campus? You can have security policies that are more specific than "PGP on every machine" vs "no disk encryption at all."

Re:Repeat after me

[ioshhdflwuegfh]

Indeed. He wrote the story as if it were a great mystery to compare timings of programs he ran before and after the change in setup.

Re:Repeat after me

[ps2os2]

I used to work in IT. As usual it depends. There are too many unknowns that we do not know about as to why the IT department mandated encryption. Having said that the laws that dictate privacy were created because everyone has become too loose with data. So it may in fact be dictated by law.
I can also sympathize with the IT department as they want to enforce a standard desktop. Having a standard desktop is *NEEDED* in most environments. Too many people install games or in some cases introduce virus's (without realizing it) and the trouble that the IT department has to go through to maintain desktops is proportionate to all sorts of variables. The real world has dumb people in it and the more dumb people the more you have to protect the desktop.

Re:Repeat after me

[duffbeer703]

Actually, it's very difficult to make that determination. The IT people aren't pushing PGP for their health -- the cost of these applications is outrageous.

I've been through this - we approached a group of people who insisted that full disk encryption would cause all sorts of issues. They weren't able to document these issues, of course. We also got the "why does this matter to us anyway... we don't have any PPSI".

Then we go down with the security folks and audit the desktops. What did we find? All sorts of sensitive information that they didn't even know that they had. (It didn't show up in their reports, but was buried within the source datasets).

This scenario is more common than you thing and encrypting everything is the best defense. In our environment, which has nearly 60,000 users, unless you are using a thin client, you get full disk encryption.

Truecrypt does that and is better

[CuteSteveJobs]

If you do encrypt why use PGP? It costs money and its proprietary. Use Truecrypt which is free and open source, does whole disk encryption which according to this can sometimes actually *boost* performance. I use Truecrypt daily and its awesome. http://en.wikipedia.org/wiki/Truecrypt#Performance http://www.truecrypt.org/

Re:Truecrypt does that and is better

[mokeyboy]

My experience is Truecrypt only does whole disk encryption for Windows systems. It will not do whole disk encryption for anything except the Windows. It also fails to do encryption for multiboot single HDD configurations. It only encrypts the Windows partition.

Re:Truecrypt does that and is better

[ConallB]

Also - Truecrypt, whilst a far superior option, lacks the enterprise tools for mass rollout, configuration and ongoing management.

Re:Truecrypt does that and is better

[Growlor]

I haven't looked into the Truecrypt FDE solution (I used a version from before they added that feature and when I evaluated encryption products for my employer), but unless they offer the ability to centrally manage the keys, then its probably not as useful in a corporate environment. For instance, corporate IT needs to be able to unencrypt the drive when a user forgets their password or is in a lawsuit (might need to provide an exact copy of the drive to show the data wasn't tampered with) or an employee leaves/is forced out.

Re:Truecrypt does that and is better

[cryptoguy]

PGP provides enterprise features that truecrypt does not. (key escrow...)

Re:Truecrypt does that and is better

[mistahkurtz]

there have been many posts saying use truecrypt, it's free, ubuntu ftw, and so on. if we're talking about home use, then by all means. i use truecrypt at home myself.

however, if you are a company, org, edu, etc, you more than likely need accountability. with free software, written by volunteers, etc, you'll typically find support from the forums, and from the developers when they have the time. open source rocks, but this is a major limitation, especially for prospective business users.

here's an example, both support/contact pages from the 2 encryption products in question:

truecrypt forums and truecrypt contact. they have no true support, as far as i know.

pgp support and pgp partners.

truecrypt is awesome, but you'll never get from them what you get from pgp. and, to the people who said "what if pgp goes away, it's closed source and you're screwed", pgp will not go away; it may be bought, sold, merged, but until we reach some utopian society where encryption is no longer necessary, pgp is here to stay.

anyway, the above links are important because: with commercial products such as pgp, you have a company, with teams of technicians, engineers, etc, all ready and willing to work with you to put together a solution for your problem. the same goes for partners and major resellers. if your company has a preferred channel through which to buy its IT gear, use them. what you get here is assistance, accountability, support, collaboration, SLAs, and so on, all the things a business of any kind typically needs. unfortunately, you don't get that from truecrypt. if your hard drive failure rate goes from 1 per month per site to 50 per month per site, who do you think will be there to fix the situation, replace the disks, and so on?

my first question for you would be, have you engaged pgp directly (as a company), or indirectly throught a business partner? if so, who is represented in these discussions? any sort of management from your department, or is it just IT? if not, i would recommend working internally to find out who is doing this project, and make sure everyone has adequate representation during all the discussions, testing, r&d, etc for this project. maybe WDE isn't for you and people in similar positions. maybe encryption for DB transactions will be sufficient. maybe you don't need anything at all.

despite what many bitter slashdotters would have you believe, most companies realize that selling the wrong solution to a client is a horrible thing, so they are typically quite eager to work with you to make sure it's done right the first time around.

so, in the end, i'd say make sure you or a representative of you and similar co-workers communicates with the project team and pgp/reseller, and that your concerns are being addressed. i guarantee you're not the first person to feel this way, and i'm sure pgp and/or the reseller have tools and procedures in place to make sure this rolls out how it needs to.

one last note. some advice above and below said to make sure your reports prove that it would cost ungodly amounts of money to keep your current productivity levels after instituting WDE. i think this is a bad idea, and like any other science project, you should see what happens, and report the results. maybe WDE would ruin your productivity. maybe it wouldn't...

Re:Truecrypt does that and is better

[jabelli]

IT puts a generic password and/or keyfile(s) on the volume/disk, then backs up the header. The user can then choose their own password, even change it daily if they want to. When IT need to get into the volume/disk, they restore the header, which restores the password/keyfile(s). You should be able to fit an entire road-warrior army's volume headers on a single flash drive.

Re:Truecrypt does that and is better

[Anonymous Coward]

Oh my god. "Free" & "Awesome" are *not* reasons to buy something. I use Truecrypt on my wife's laptop, but I would never deploy it in a enterprise setting!

How do you do user password recovery? User groups? Automated deployment? Logging? What if the user is half way across the world and needs to do a password recovery?

Re:Truecrypt does that and is better

[CodeBuster]

Mod the parent up please, he knows what he is talking about. TrueCrypt FDE actually stores the encryption key for the drive in the header on the drive itself which is itself encrypted separately using the password provided by the user via the TrueCrypt boot loader. If the recovery disk or a copy of the header is maintained from the initial conversion to full encryption AND the drive is not reformatted and re-encrypted in the meantime then restoring the previous "password" is as simple as overwriting the new header with the old header (the actual disk encryption key hasn't changed, just the key supplied by the user in the form of the password to decrypt the header).

Re:Truecrypt does that and is better

[Anonymous Coward]

enterprise management would be one reason I can think of.

I use truecrypt and its great, but afaik it doesnt scale well and provide easy management. You'd have to have a massive catalogue of all these recovery cd's for your users when they forget their passphrase.

Re:Truecrypt does that and is better

[Growlor]

That's an interesting approach and solves the ability to recover it (unless you need to do it remotely???) for a small number of machines. For larger entities, I think this would be unworkable (too much overhead matching which header goes to which drive/PC) for a large organization though.

Re:Truecrypt does that and is better

[jabelli]

"Large organizations" have asset tags. Use the tag number as the initial password and the filename. Keep the headers on an encrypted USB drive. Better yet, keep them on lots of encrypted USB drives.

But you're right, you couldn't do anything remotely if the boot partition is encrypted. In that case, however, it doesn't matter what you used.

If you need the other features of PGP Disk, by all means use it. Just remember that there's TrueCrypt, which is "good enough" for most purposes.

Re:Truecrypt does that and is better

[Anonymous Coward]

Actually, you can do remote decrypt with some of the products (like the one we chose.) There is at least one that allows a challenge/response method for helpdesk use (although you then have to worry about how you authenticate your person who calls to say they "forgot their password" to ensure its not the guy who just stole that laptop.)

Re:Encryption is good for security, bad for perfor

[GoulDuck]

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).

Re:Encryption is good for security, bad for perfor

[calmofthestorm]

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.

Put things into perspective

[Anonymous Coward]

Current optimized kernel versions of AES manage about 50mb to 60 mb/s on a 3ghz cpu. This _maxes out_ the core on which the IO thread is running on. This is not a linux-specific quirk, but just plain mathematics. AES is fairly expensive, and neither blowfish nor twofish are faster by any meaningul value. If you're not blessed with a multicore CPU, full disk encryption will most certainly crawl your whole system down when you do anything disk-serious; and even with multicores, your system will be sluggish in the worst of times when you do heavy IO (think: the keyboard irq handler not caaaaaaaaattccchhhhing up.)

You can have yourselves one of those PCI encryption addon cards (Soekris sells some), but their bandwidth is very limited as well (155mbps, last time I checked).

Consider carefully if you want privacy, or easy throughput. You can't have both right now.

Re:Put things into perspective

[Soulshift]

Consider carefully if you want privacy, or easy throughput. You can't have both right now.

The organization that would trade performance in favor of security deserves neither!

Re:Put things into perspective

[Richard_J_N]

One thing you can do is use ionice. ionice is the equivalent of "nice", but for disk-bound, rather than cpu-bound processes.
That will keep the system a bit more responsive.

Suck it and see

[RationalRoot]

Get two identical machines. Put full disk encryption on one, run you app on both with the same dataset. Then you will know if it's worth kicking up a fuss over. Though if you can't do this little bit of research, I suspect genes may be a little complicated for you too.

This has happened

[DynaSoar]

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.

Re:This has happened

[emj]

This is a very old problem, that's why you have a backup of the encryption key somewhere, I'm sure PGP has such a system builtin to their tools.

Re:This has happened

[Registered Coward v2]

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.

Your experience points out why it is necessary to keep the passwords in a secure location for such an eventuality.

We had safe codes that were known to 1 person - with the combo locked away in another safe. That way, if the 1 person could not open the safe; we had a secure backup plan to gain entry.

The goal is to keep the information safe from unauthorized access; storing the keys (hardcopy) in a secure, locked location would still maintain security while providing a way to gain access if needed in an emergency.

Re:This has happened

[Growlor]

Exactly. This is one of the reasons for using a mature solution (such as PGP or one of its successors and not something like Bitlocker) which offer centralized key management and recovery. It is EXTREMELY difficult to trace all the possible places a Windows OS might write data to (and maybe even a *NIX one too) and then make sure all that data is deleted and overwritten to prevent forensic recovery. This gets to be MUCH harder if you start copying the data to thumb drives (assuming that it is not just you and other people who might use the same drive as the one housing all their MP3's - and thus don't want to completely wipe it - or worse pirated games that might contain malware!)

Re:This has happened

[cryptoguy]

pgpdisk provides key escrow features for enterprise manageability.

Re:This has happened

[blowdart]

Interesting how you assume BitLocker doesn't support recovery/key management; if the machine is in an AD environment then you can enable key escrow to the AD which will allow for recovery of encrypted drives. As BitLocker encrypts whole volumes, like TrueCrypt and others then it won't matter where Windows writes data, because the entire volume will be encrypted. Your point about thumb drives still stands.

Re:This has happened

[Kaenneth]

I thought Bitlocker supports managment via Windows domains/Active Directory?, perhaps you were thinging of Truecrypt?

Re:This has happened

[Anonymous Coward]

This was just a bad implementation of whole disk encryption. When done properly you will set up some kind of key escrow for I.T. administrators to get in, in case you forget it or get hit by a bus. Certainly WinMagic SecureDoc will do this, I assume others will. This program will also let you use a boot disk for recovery purposes.

Re:This has happened

[lucifuge31337]

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.

Actually, enforcing TreuCrypt or a non-enterprise version of PGP can. If you do it right, the enterprise admin will be able to decrypt data from anyone. This would be the #1 reason to use the (evil, have to pay for it) PGP version over TrueCrypt.

Re:This has happened

[Growlor]

Oops, you are correct, it can do this in AD. I think I it was actually an issue specific to us: we were still using the 2000 version of AD at the time Bitlocker came out and I think it requires 2003 (not an AD dude so this may be the wrong terminology, but hopefully it conveys the meaning even if its wrong.)

Re:This has happened

[blowdart]

Yea it does, at a minimum you need AD to be 2003, if you extend the AD schema (and scripts are supplied to do so)

I've another fear

[kanweg]

For my company, data has to be kept secret. Yet we do not do encryption. The fear for corruption of data is far bigger than the chance that a cracker gets access.

As to personal experience: With TrueCrypt, changing between accounts (on a Mac) with TrueCrypt open can wreak havoc. The data can be copied but the secure thingie has to be re-created from scratch. We cannot have encryption working properly 99% of the time. It must be 100.00%.

Bert

5 reasons

[Knightman]

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.

Re:5 reasons

[kefa]

I agree - it seems to me like:

1. data in the data centre should not be encrypted (assuming your data centres are physically secure)

2. everything outside the data centre should be encrypted

An exception to this might be where a 3rd party is managing your data centre (e.g. traditional outsouring or the cloud)

As you say, products like VMware ACE and Sun Ray help to keep sensitive business data unencrypted in the data centre where it is physically secure, or encrypted when it is 'out and about'.

Re:5 reasons

[Growlor]

You have some good points, but I disagree with your conclusion "a policy of having all disks encrypted is bad:" I completely agree with your point #1, but its probably not realistic to demand this at all organizations. For #'s 4 and 5 the performance penalty is negligible on modern PC's (except for very extreme situations such as database servers.) Even then you might still consider it if the data was important enough and you could not provide some other means of guaranteeing it against physical loss/theft. As for 2, current FDE products are so end-user friendly that having people try to get around them just because you added encryption is really not a concern. Finally, for #3, I am not sure. You are correct that a failed drive means you now have a very high liklihood of catastrophic loss, but you really should make sure your users have a good backup system in place before or as part of your encryption roll-out.

Re:5 reasons

[Anonymous Coward]

1. Sensitive data should not be stored on a computer that can be carried away or easily accessed, with or without encryption.

That's all well and good, as long as your employees never need to work remotely, like from home, on travel, at customer sites, etc. You do realize that just about any data of any value has some sort of sensitivity associated with it, right? There are so many different categories of information requiring protection that just about anything useful will fall under at least one of them. Your solution would do away with corporate laptops, VPNs, etc. and force businesses back into the stone age of computing.

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.

Only if the implementation of said security measures impedes the employees' ability to work (or do whatever they're trying to do). Complicated data handling procedures are likely to have this problem, but whole disk encryption is usually a one-time annoyance (except when the encryption goes belly-up and kills the whole system, but that's what backups are for). If performance and/or access is an issue, get a waiver. If there's no waiver process, then print up some resumes, because you work for exceptionally mentally challenged morons (as opposed to your garden variety morons who know enough to ensure that there is always a way for management to get around any blanket policy).

3. Failing or failed disks goes from a serious problem to a critical problem for recovering data.

Which is no worse than lost/stolen laptops. Given a reasonable upgrade cycle and the ease of loss/theft, I would guess that drive failure isn't that big of a concern on systems that should be required to have whole disk encryption. Whatever is in place to allow you to recover from loss/theft/encryption meltdown should suffice for disk failures.

4. If you are running I/O "happy" software you are going to take a perfomance hit.

See number 2.

5. It's not a "green" solution since the encryption is done in software and the computer is going to use more power.

Now you're reaching.

Re:5 reasons

[macaulay805]

I would have to agree with your "Sensitive data should not be stored on a computer that can be carried away or easily accessed, with or without encryption." statement!

Physical security *ALWAYS* trumps logical security.

Lets not forget the limitations on encryption. If it can be decrypted, all it takes is time. Regardless who has the keys. Hell, sometimes event if it wasn't ment to be decrypted, it can be with sufficient resources (ie; Rainbow Tables).

Re:5 reasons

[RockDoctor]

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.

You use (have used) the past tense? Do you know something that we don't?

Drive Errors?

[CopaceticOpus]

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.

Re:Drive Errors?

[Anonymous Coward]

If a sector goes bad, you lose the sector, no more. This isn't just for resilience of data - if you had to re-encrypt a sizable chunk of the disk for every small change made to it, it wouldn't be usable at all! So the sectors are encrypted independently.

http://en.wikipedia.org/wiki/Disk_encryption_theory

Re:Drive Errors?

[Anonymous Coward]

a solution would be to have copies of all the encryption keys stored in a locked safe with the network admin and passwords for those keys in a different locked safe with another admin. (all stored on paper to avoid EMP/magnet/corruption issues)

similar to the two key system used for nukes.

Re:Drive Errors?

[mevets]

one sector of metadate [ inodes, etc ] and you can lose much much more. It is true in plaintext filesystems as well, but patterning can often be used to resolve this. Random data is just random data.

Nice to see the entire investment community of True Crypt is out to shill for them today....

Re:Drive Errors?

[Anonymous Coward]

this is not how whole disk encryption works. A bad sector means you loose a sector....But loose a password, now thats different.

Re:Encryption is good for security, bad for perfor

[IWannaBeAnAC]

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!

It's impossible to compress encrypted data

[kaltkalt]

It is impossible to compress encrypted data, or at least data that are properly encrypted. If properly encrypted, the resultant cyphertext should be completely random - any patterns mean it is pseudorandom and thus not properly encrypted (by "proper" I mean unbreakable by means of cryptoanalysis, for example a simple substitution cypher does not result in an even, random distriubtion of letters - there will be more of the letter that represent "E" than the letter that represents "Z"). It is impossible to compress completely random data. As such, it is impossible to compress properly encrypted data, since it should be completely random. For this reason you cannot compress a PGP encrypted file (or hard drive, for that matter) since the cyphertext of the PGP encrypted file is completely random data, even if the plaintext is nothing but the letter "W" written over and over again ten thousand times.

Re:It's impossible to compress encrypted data

[Duckie01]

You are right... you can't compress encrypted data very well... but you can encrypt compressed data just fine!

A compressed partition on an encrypted disk would be encrypting compressed data.

Re:It's impossible to compress encrypted data

[Anonymous Coward]

What about encryption of compressed data? Because that's what we're talking about

Re:It's impossible to compress encrypted data

[kaltkalt]

Sure you can encrypt compressed data. I was just making a general comment on the statement that "certain forms of compression are also incompatible with PGP whole disk encryption." It seemed germane to the topic. But yes if it's already compressed then it can be encrypted.

Re:It's impossible to compress encrypted data

[Sloppy]

Everyone compresses before they encrypt. Everyone. That's why I think the whole compression issue is bogus.

Re:Encryption is good for security, bad for perfor

[nmg196]

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.

Re:Encryption is good for security, bad for perfor

[bhima]

The FBI has already demonstated that it is extremely easy to bypass the security on those drives. I would not use them.

Re:Encryption is good for security, bad for perfor

[borizz]

Maybe they got to 1% by using multiple cores?

I think multi core processing was easy to implement (it's a block device after all, you can separate it easily if you choose the right mode of operation for your cipher).. They also implemented AES in assembler to speed that up.

Re:Encryption is good for security, bad for perfor

[cheater512]

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.

From me going to a fully encrypted machine...

[Kjella]

From me going to a fully encrypted machine I'd estimate the impact to be about half a Moore. That is, assuming you're replacing hardware with current all the time you'll see a net zero gain for a year and from there it'll be business as usual. I haven't been doing any high-performance scientific benchmarks but even when playing a 1080p movie with torrents running in the back, it runs just fine and it's as intensive as any normal desktop is likely to be. I'd say you're worrying too much, check it out and if it really bogs you down put up a business case that says one of three will happen:

a) Productivity declines
b) Get an exemption
c) Get new hardware to make up for it

Just make sure to put a dollar value on it so the PHBs understand what you're talking about, and I'm sure this will work out just fine.

Re:Encryption is good for security, bad for perfor

[xouumalperxe]

Presumably, he meant that encryption done on the disk itself is transparent to the rest of the computer. What you see is a comparatively slow hard drive, not the existing resources (ie, CPU) being eaten up by the encryption job and low disk throughput. Same all other dedicated controllers: you're offloading processing to a dedicated chip, so, for the purpose of generic programs on the CPU, you can assume there's no performance hit.

Re:Encryption is good for security, bad for perfor

[calmofthestorm]

It may incur overhead but it need not. Consider that you don't need "instant" encryption, you simply need a device inside the hard drive between the computer interface and the actual storage medium that is capable of encrypting and decrypting at or above the drive's maximum throughput speed. This need not be "instant", it merely need be fast enough block-by-block to pass the data along. Consider that hard disks store data in blocks, not streams.

Random Experiences with disk encryption

[quietwalker]

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.

Re:Random Experiences with disk encryption

[Deb-fanboy]

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.

Yes that is so commmon on the North Sea offshore platforms where I work. A large number of the PCs have user names and passwords on stickers on their monitors. The stickers are changed once a month as IT impose a password change.

Re:Random Experiences with disk encryption

[Locklin]

Solution: http://www.truecrypt.org/docs/?s=rescue-disk

Truecrypt won't actually let you run whole disk encryption without creating a rescue disk.

Re:Random Experiences with disk encryption

[STrinity]

Guess what happens if the corruption doesn't allow you to run the encryption app's boot loader?

You pop in the boot/recovery CD the encryption app forced you to create before it'd encrypt the drive? At least that's how it works on TrueCrypt.

Re:Random Experiences with disk encryption

[Anonymous Coward]

So encrypt the central server too. What you're doing is what we in the industry call "making backups", and is a good idea regardless of whether you're encrypting your laptop. Your laptops and the backup server should both be encrypted, though.

Re:Random Experiences with disk encryption

[Anonymous Coward]

PGP WDE has multiple ways of accessing drives that can't be booted from. There's WinPE, which is a bootable Windows environment which allows the use of the PGPWDE utility; you can also slave the drive to a DSR system with WDE installed; and finally, you can use a "BOOTG" recovery disk to decrypt the drive.

Re:Random Experiences with disk encryption

[Knara]

The thing that keeps me from liking FDE is the probability of drive failure on an end-user machine. Not just the MBR failing, but physical trauma resulting in the need to send the drive to a data recovery firm (or, say, a drive motor burning out). With the number of laptop users I have wandering around beating their laptops, having DHS abuse them at the airport, or people's dog's knocking them over, it's a concern to me.

As far as I know, the available methods won't allow them to recover that data.

(I'd be happy to be wrong)

Re:Random Experiences with disk encryption

[Anonymous Coward]

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.

I would say it defeats half of the purpose, but IMHO it is still inherently more secure, especially when you have internet-facing services such as VPN access or webmail. It infinitely easier for someone to attack a user's password if it is "jeff" than if it was "Iluv69Woodstock". If that guy happens to have it as a post-it under his keyboard, that means only 30 people have access to it. And if they have access to his keyboard and post-it they could just as easily steal the computer or use a boot CD or otherwise. Obviously this is somewhat simlified, but trust me, people will use as easy of passwords as you let them. And they will only change them when forced to.

Instructing users to use a phrase to generate and remember their password makes them much easier to remember. I administer quite a few PC's and it is quite infrequent that I find someone who has their password written down.

Don't resist!

[Anonymous Coward]

I know a guy who works in IT at Decode that works with human genetics. They have a strict policy on fully encrypted disks, passwords on everything etc... The founder Kari Stefansson was really annoyed because of all this, but like a typical professor he loses his laptop every few months so good thing there's a double encryption.

If you see a big performance hit you should look at more hardware rather than resisting the protection.

IMHO confidential data should be encrypted! How often do we see news on slashdot where people lose unencrypted laptops with highly confidential data. Encryption should be mandatory regardless of the performance hit when dealing with confidential data. It's like going to a $7 hooker without using a condom and risk not getting an STD.

Re:Encryption is good for security, bad for perfor

[calmofthestorm]

"those drives"? as if they're all the same?

Come come. Software encryption is trivially vulnerable to a coldboot attack.

In any case I'd want to see a link, you can't lump all "encrypting drives" together as if they use the same method (unless they do).

Of course, I wouldn't really be surprised if it were breakable, I'd simply like to see support. Me, I use hard and soft becaues I'm just tinfoil like that. Don't even have anything to hide either, just like my privacy.

Re:Encryption is good for security, bad for perfor

[calmofthestorm]

At some point it's cheaper to pay for armed security guards and cameras and put them in a fortress. Encryption for laptops that ever leave the building is a no-brainer. Desktops in offices I can see argued either way.

Let's build a Beowulf on LUKS!

Why are you writing to slashdot?

[Idaho]

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.

Re:Why are you writing to slashdot?

[EmagGeek]

Trust me, writing to slashdot will get better results. Corporate IT automatons don't listen. They rule by decree, and are intransigent. Drunk with power, they are not interested in the opinions of their users.

Re:Why are you writing to slashdot?

[TuaAmin13]

Bargain with IT. In exchange for not encrypting the drive, you can physically secure the machine, with stuff like door codes.

Another option is to go higher than IT, to some administrator type. State that your research project is in jeopardy because of the new rules, and if you cannot get the project done (but you could if the restrictions were removed for your lab), there won't be any more grants. Administrators might be more concerned with the prestige of the lab than IT, so they'll pass a decree to the IT "automatons" (as EmagGeek said), which in turn will help you.

Re:Why are you writing to slashdot?

[Anonymous Coward]

Another option is to go higher than IT, to some administrator type. State that your research project is in jeopardy because of the new rules, and if you cannot get the project done (but you could if the restrictions were removed for your lab), there won't be any more grants. Administrators might be more concerned with the prestige of the lab than IT, so they'll pass a decree to the IT "automatons" (as EmagGeek said), which in turn will help you.

As an IT admin I've dealt with this tactic. I've gone to corporate counsel and have the drum up the worst possible scenario for damage from data theft and then I scare the PHB with it. It works like a champ.

The liability of a scientist acting like a spoiled child is generally negated when dollars signs are attached to their potential screwup.

Re:Why are you writing to slashdot?

[Anonymous Coward]

It's obvious he has a grudge against IT in general with comments like "probably because most of them are written by IT pros who are only focused on the security, and not usability". I doubt his IT department is the cause of the problem anyway. Sounds like a middle management decision.

Re:Why are you writing to slashdot?

[Anonymous Coward]

In most academic HPC settings, the IT has their own middle maangement and is a bureaucracy unto its own. It is rare for the scientist to not periodically resent the disconnect between that IT group and his funded research.

Sensible IT in this environment would create a roadmap for converting to FDE, and simply ask the scientist to budget for FDE-capable hardware in their next round of grants and purchases. You would never suggest some half-baked modification to existing deployed systems, but rather plan for their retirement and replacement. Hardware solutions which store keys in TPM and use the disks' native encryption would be enough for legal cover-your-ass due diligence, which is all the IT and management care about anyway. As an added benefit, it scales up with disk device count, and can be done passphraselessly, which matters for your HPC cluster of hundreds or thousands of headless nodes!

Re:Why are you writing to slashdot?

[ddeboer]

Riiight... good one - and have Mordac the Preventer of Information Services turn him in to Corporate Rent-a-Cops (oops, sorry Mr. Internet Police, I mean "Corporate Security") as a security risk?

Re:Why are you writing to slashdot?

[Anonymous Coward]

I have to admit I was pleased alaederach posted this query. I am facing a similar situation and this discussion is helpful.
No-one (as far as I have noticed)has posted any comments on the reliability of the software - has anyone had a hardware failure because the encryption software failed?

Don't encrypt bulk, public data

[MichaelSmith]

...because doing so makes the crypto easier to crack. The attacker can compare the plan text with the encrypted data and reverse engineer the key. So your data may actually endanger the small amounts of sensitive data you actually carry.

Re:Don't encrypt bulk, public data

[Anonymous Coward]

That's if the cipher is vulnerable to a known-plain-text attack

Obligatory

[Whiteox]

I, for one, welcome our Tetrahymenian Overlords!

Re:Obligatory

[ShaunC]

I think I'd be happier with tetrahymenian overladies...

Re:Obligatory

[Whiteox]

I, for one, welcome our Tetrahymenian Overladies!

Re:Obligatory

[ShaunC]

Cool, now that I can get behind. Or from behind. Four times each...

Think about the purpose of Full Disk Encryption

[hAckz0r]

The only protection that Full Disk Encryption gives is if someone physically gets their hands on the machine that they can not boot the machine and read its contents. This make perfect sense for laptops but makes little sense for any pertinently fixed location workstations. A laptop will physically leave the premises so it leaves itself open to theft, but a workstation (assuming you have some decent form of physical security) is much less likely to need this protection. Once a workstation is booted and the disk drive unlocked digitally then any hacker that gets a foothold on the system would then have access to it, so all that overhead of full disk encryption does no good unless the encryption is done per-user-session. When you need assess to the data you authenticate and start decrypting then, and keep it encrypted across the network. Yes, that data that you speak of should be encrypted, but you must encrypt it at the correct level to actually increase its security rather than just slowing down the machine. Anything short of that level of control and you are just fooling yourself into thinking you have protected the data. Fool-Disk-Encryption is not always the answer.

Re:Think about the purpose of Full Disk Encryption

[kefa]

True, but theft of a desktop from a physical location is still a distinct possibility. I have worked in offices where thefts of desktops have occured.

For me, given that a laptop can be stolen when powered up or down, encryption gives the added security that whenever I leave my (screen-locked) laptop unattended I know that the data is still totally inaccessible.

Re:Think about the purpose of Full Disk Encryption

[Anonymous Coward]

Exactly. Encrypting rackmounted servers with low risk of theft and considerably higher risk of being compromised while perpetually online seems like a gross misuse of resources. Protect physical and remote access to your servers. Your university should install good, solid locks and a security system ala a real datacenter and move everything potentially sensitive in there.

That said, when trying to get an exception and work around these asinine policies I'd suggest attempting the above. Convince them that you can control access to the servers. Convince them to put you on a separate pipe so that you're not at risk of ever having greater privileges on a local network that might make it easier to compromise your sensitive data. Convince them that you're planning on releasing whatever it is that you're storing publicly anyway.

Give them valid reasons to let you work around their policies in this particular instance so that you can get your job done. Then start working towards polices that make sense.

Re:Think about the purpose of Full Disk Encryption

[STrinity]

The only protection that Full Disk Encryption gives is if someone physically gets their hands on the machine that they can not boot the machine and read its contents. This make perfect sense for laptops but makes little sense for any pertinently fixed location workstations.

There's no such thing as a permanently fixed workstation -- sooner or later it, or the hard drive in it, will be thrown out. There've been enough stories about people who've bought second-hand drives and being able to get data off them, either by just installing them on a computer, or by running disk recovery software.

If you think your company might some day replace you with some numb-nuts who doesn't know about Derek's Boot-and-Nuke, it makes sense to require encryption even on desktops.

Re:Encryption is good for security, bad for perfor

[KStrike155]

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!

People misunderstanding the question...

[wanax]

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.

Re:People misunderstanding the question...

[kefa]

His lab works with a protozoa, and has massive computational requirements. There will never be any patient data near his lab...

Crikey Alaederach! Get that encryption software installed pronto. Your personal details are already being leaked on to the web!

Re:People misunderstanding the question...

[yttrstein]

There is no misunderstanding the question. A $USER is frustrated because the security is slowing him down. $IT_DEPT is frustrated because $USER does not understand why it's so important and keeps whining about it.

In the Right World, where all things are Right, and all people only think the Right thing at all times, $IT_DEPT wins.

What will happen here is anyone's guess, but really all $USER needs to do is adapt to a changed environment, which is never, never as difficult as designing that environment in the first place. $USER doesn't know how good he's got it.

Re:People misunderstanding the question...

[Lumpy]

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.

Re:People misunderstanding the question...

[mikkelm]

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?

Re:People misunderstanding the question...

[flappinbooger]

The solution for the story submitter is simple, then.

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.

Re:People misunderstanding the question...

[Software Geek]

I think the GP was intended as $SARCASM, but I'm not sure. That, of course, makes it the best kind of $SARCASM.

Re:People misunderstanding the question...

[b96miata]

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.

Re:People misunderstanding the question...

[yttrstein]

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.

Re:People misunderstanding the question...

[mysidia]

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.

Re:People misunderstanding the question...

[KevMar]

We are about to run into this issue head on where I work. Not all computers need to be encrypted. But all mobile devices are required to be encrypted (if they contain EPHI or not). Our research areas tend to use alot of laptops. Alot of them are perrsonal laptops (they also get encrypted).

While most people make rules and talk about patient information, they should include financial and grant in those policies. The requirement to keep them secure and the cost if it gets stolen to the institution is the same. So all private date gets included in the policies and it all gets encrypted.

If you are in this situation, you just need to provide an alternate way to midigate the risk of running unencrypted. The risk they midigate is stolen hardware. You need to get rid of all your laptops. You need to keep the door to your lab locked. You also need to secure the physical machine with a securuty cable and lock. The last one my be a bit much, but if its a tower its not a big deal.

This is an opprotunity for you to ask for a faster computer because they are insisting that its encrypted and its impacting your processing of research data.

Re:People misunderstanding the question...

[Anonymous Coward]

...cause I know when I mod comments, I always review the submitters entire body of work to ensure that I take their message in correct context.

Re:People misunderstanding the question...

[Stone316]

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.

Re:People misunderstanding the question...

[Gr8Apes]

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.

Re:People misunderstanding the question...

[JoeMerchant]

In the world I live in, the budget is never there.

Re:People misunderstanding the question...

[Sancho]

There are a lot of good reasons to disallow non-managed network equipment. What if one of the devices behind that switch starts killing the network? The admin's only option is to disable that port, which kills everyone's connection, and then everyone will start bitching about it. What if someone brings in a router and plugs it in wrong? Now they're serving DHCP out to the building? People with unlimited IT budgets might say, "Get gear that kills unauthorized DHCP servers." People with limited IT budgets will get bitter and hostile at this point.

IT is there to support the users, but it's perfectly reasonable for IT to be the ones adding on to the network. Need more ports in the conference room? Let me put one of my switches in there.

Re:People misunderstanding the question...

[Gr8Apes]

You're either the worst type of admin (and it certainly sounds like it with your ham-fisted policy statement) or your business has no real negative impact from your policy, in which case it's ok.

In the presented case, it sounds like there is significant disk I/O. Adding an encryption layer to disk I/O that's not hardware driven is going to slow down disk access, possibly significantly. The type of modeling discussed generally uses huge amounts of resources and can strain all current systems to near breaking points. I used to do similar work modeling large structures, and even the Crays and Convexes I used would take many hours to run highly optimized code that reduced memory requirements as much as possible. Output was measured in GBs, even compressed.

An encryption layer on a fully utilized machine would have significantly slowed down processing, as Disk I/O was already a bottle neck.

Re:People misunderstanding the question...

[Wovel]

Interesting but.. The absence of an event does not mean the burden your policies place on the end users was necessary. So you are saying you would not grant a waiver to a blanket full disk encryption policy for a lab that had higher performance needs and no sensitive data? Perhaps your policies are written better than the institute where the submitter works. Blanket security policies with no procedure to obtain waivers are nearly always bad and are generally indicative of an IT organization that is poorly managed and not designed to meet the needs of the user community.

Re:People misunderstanding the question...

[rob_benson]

mikkelm: As a network security administrator I have to mention that often security is implemented DESPITE the fact that has impact on user productivity. I generally operate off of the "One weak link" theory: if any machine on my network has poor security, it puts everything at risk. Sometimes I have to implement security measures because they are for the good of the organization as an entire entity. I spend hours agonizing over the impact that some of the policies and systems I implement have on productivity, and the folks at my work are very understanding about it. I'm glad I work with folk who know that I am looking out for their best interests and are willing to work out compromises instead of going negative. Usually I can find a middle ground to maintain security while providing availability that my guys need to get work done. Mikkelm's attitude would make it really frustrating to work in my environment.
That said. I would bring this issue up with the IT department first. I generally only encrypt drives if necessary; If you do not work with classified data I just would not waste my time. Maybe an alternate arrangement where only certain folders are encrypted could be made. We do this regularly by my work.
In my 9 years in technology I have always worked in places where the IT department was pretty well regarded: I think this is because the departments were not antagonistic towards each other and did not hold grudges.The seeming lack of communication between the poster and his IT dept. puzzles me; why post it on slashdot instead of communicating concerns to IT?
If your tech dept makes it difficult to communicate with them then there is a more serious issue here than just encryption -- they have a service issue.
If you scream to Slashdot before contacting your IT department, then maybe you have an issue.

Re:People misunderstanding the question...

[duffbeer703]

The real issue is that the management of the institute is afraid of the liability that the leaking of patient data could present.

In this case, it might make sense for the lab to implement some sort of well-documented, auditable process of formally separating any personal information from the data sets.

Re:People misunderstanding the question...

[TheMohel]

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).

Re:People misunderstanding the question...

[locofungus]

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.

Re:People misunderstanding the question...

[Anonymous Coward]

We could always use a "-5, Self-Replying Tool" mod around here

Re:People misunderstanding the question...

[Antique Geekmeister]

This is not for 'the network'. This is for the patients whose data is on those systems, and for whome it's life-critical private information. It's also for the lawyers, to be able to say "we encrypted it on the servers and laptops, it didn't get stolen from us".

It's also much easier, and in many cases cheaper, to say "encrypt everything!" than to work out policies and exceptions. Maintaining those exceptions cost expensive technical and management time: is making the exception worth it? Or can you just buy another encrypted server to split the load?

Re:People misunderstanding the question...

[Anonymous Coward]

Users need not be consulted. If legal says they want the data encrypted and the CIO/CTO agrees that they can absorb the overhead the change imposes, users can howl as much as they want. Users may voice their feedback about items directly related to their tasks, but certainly not about whether this or that product uses more or less cpu or whether they can do this or that to their hard drive or whether there's a missing 1% of CPU cycles in their computer.

It would seem as the OP has a bad case of entitlement and whine.

Re:People misunderstanding the question...

[Sancho]

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.

Re:People misunderstanding the question...

[Sancho]

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.

That's a pretty silly and arbitrary, but in a lab setting, you may be better off with a test network, anyway, like yours.

I was mostly talking about actual, reasonable measures, not measures that are in place because the admins can't figure out something if it doesn't connect to the AD.

Re:People misunderstanding the question...

[ArhcAngel]

...network administrator...the policy stands unbreakable, period. There is no compromise.....

the user's needs are seen to

You say the security policy is unbreakable but your let users touch the network. You my friend live on the EDGE! There's no way I'm letting actual users get anywhere near my secure network.

Re:People misunderstanding the question...

[sabs]

The bigest problem I ran into with Truecrypt whole disk encryption was the lack of a pagefile/virtual memory.

FOr most people this day, it might not be a big deal, but for some of us this has a huge performance issue.

Re:People misunderstanding the question...

[mrraven]

I hope you don't also consider yourself to be some kind of capitalist or something. Excessive security that reduces your efficiency is not going to help your business compared to another company that has more flexible security policies that lock up actual sensitive data while letting those with non sensitive data work at maximum computational efficiency. Your attitude is that of a Soviet bureaucrat that policy consistency trumps actual on the ground working conditions, and it will only be to your loss when your competitor gets their computational work involving non security hazard done more quickly.

Re:People misunderstanding the question...

[twostar]

Don't forget to calculate the increase personnel time required to meet current output rates. This is often many times more $$$ then what some upgrade hardware costs. Then if they're ok with decreased productivity, and therefore higher man hours, then it's purely a management decision. You can also point to this report at a performance review as a reason goals were not met.

Re:People misunderstanding the question...

[yttrstein]

I don't. I've been modding down randomly ever since I realized a couple of weeks ago that slashdot had been taken over by children while I was away. See, it's all part of my brilliant scheme--serious replies that are heavily weighted to mod up (it really isn't very hard to impress the current crop of modders, unfortunately) in order to generate strangely good karma and points.

Then I pretend I'm 16 years old again and know everything and just start modding everyone down who I think is even a little bit of a jerk, no matter what the content of their post. See, I'm fitting right in.

Don't worry, I'll get tired eventually and diminish back to reddit.

Re:People misunderstanding the question...

[Anonymous Coward]

Mod parent up!

Re:People misunderstanding the question...

[yttrstein]

Of course it's incredibly important to not just slam a ham-fist down on a desk and try to herd everyone into one's own philosophy without first being very careful to build a policy that makes sense in the environment.

In my case, everything absolutely must be encrypted inside the network. That very often means multiple layers (a truecrypt volume for example being read over NFS piped through SSH happens often) of encryption, just to be absolutely certain that things are being done correctly.

The reason I do things this way is because a long time ago I learned from a brilliant CTO that no matter what, the safety and integrity of customer data is far, far more important than the immediate comfort of any single or small group of employees.

That is, if a security policy is implemented that makes everyone miserable, it is of course the wrong policy and should be modified. But, if a security policy is implemented that makes four of six developers miserable and really no one else, then those four developers can just deal with modifying their habits (which by the way, are usually the worst in the loudest whiners).

Re:People misunderstanding the question...

[ThePiMan2003]

Except in this case $IT_DEPT is being stupid because $USER does not need full disk encryption for NON-HUMAN data on computers that do not leave the facility. If someone has broken into your research lab to steal a hard drive you have other problems. Also, why would you install full disk crypto on servers?

Re:People misunderstanding the question...

[yttrstein]

I consider myself a person who runs a company that specializes in PCI DSS (and similar) certifications, and therefore must absolutely be the model for the best case scenario of the same.

Re:People misunderstanding the question...

[Free the Cowards]

The problem is when the IT guys think that prohibiting a switch in a conference room to provide connectivity for a few hours falls under the heading of "reasonable".

Dilbert's concept of "preventer of information services" is more truth than farce. Most IT guys I've encountered are more interested in "keeping the network healthy" than actually letting people get work done. If you have a better way to let six people all connect to the network from that room, then fire away. But "sorry, you can't plug that in, and there's no other way to get what you want" is quite simply the wrong answer.

Re:People misunderstanding the question...

[idsfa]

Virtual systems will NOT properly reflect the overhead. The I/O costs in a VM are much higher than those on real hardware. Test the system you are going to have, not a mock-up.

Re:People misunderstanding the question...

[Sancho]

Most IT guys I've encountered are more interested in "keeping the network healthy" than actually letting people get work done.

Devil's advocate: if the network isn't healthy, then no one gets work done. If the conference room has too few ports, six people don't get work done.

But like I said, the proper solution is for support to support you. If they don't want you plugging in your equipment, they should have a solution that will let you do what needs to be done. Most of the time, that would mean putting a temporary managed switch in that room. If the IT guy isn't willing to do that, they're likely just on a power trip, and such behavior should be dealt with.

Re:People misunderstanding the question...

[locofungus]

I was mostly talking about actual, reasonable measures, not measures that are in place because the admins can't figure out something if it doesn't connect to the AD.

But that's quite possibly the situation the OP is in.

I've no idea what he is doing but, hypothetically, he's just spent $10m on a set of high end PCs to run his simulations.

Someone now proposes to reduce his computing capacity by some arbitrary amount because he has to run disk encryption.

It's perfectly reasonable to have a rule that, by default, every disk must be encrypted. But making that a blanket rule with no exceptions is foolish.

"I'm sorry. I realize that this is going to hamper your research and may require you to buy additional hardware to maintain performance but as you're processing medical X-rays that can, potentially, be linked back to a patient, you're going to have to use disk encryption on your compute farm because there are potentially too many people who have physical access to the machines and there's too much risk of someone walking off with one or two machines together with their disks."

"Ah, I see. Although You're processing medical X-rays, your compute farm is in the controlled server room. We already have processes in place to ensure that disks etc are not removed without being securely wiped. Yes, I think we can allow an exemption for those machines."

"Ah, yes. You're analysing the genome of protozoa[1]. Yes, we'll give an exemption for your compute farm. This exemption will only apply until your current research is complete. We'll reassess whether the exception is still be appropriate when your next project is in planning."

[1] I looked up tetrahymena - I'd never heard of it before

Tim.

Re:People misunderstanding the question...

[russotto]

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).

Take a patch cable. Plug one end into a switch. Plug the other end into another switch on the same network. Or even the same switch.

Happened twice at my old office, once during an office move, once just by accident. More sophisticated equipment detects this problem, but we just had dumb switches.

Re:People misunderstanding the question...

[element-o.p.]

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.

Re:People misunderstanding the question...

[Anonymous Coward]

He may have had security breaches, but as far as he knows he's had no security breeches.

Re:People misunderstanding the question...

[kscguru]

It's good enough for an apples-to-apples comparison - GP suggested comparing an in-VM setup w/o encryption versus an in-VM setup w/ encryption. I/O costs are higher, but the cost is in latency, not bandwidth; a large-data research number-cruncher depends more on bandwidth.

Not everybody has the budget or time to put together two identical systems for comparisons like this.

Re:People misunderstanding the question...

[Free the Cowards]

Yep, IT is a delicate balance. They have to keep the facilities working even though their users are continually doing things to destroy them.

The trouble is that those things which destroy IT facilities are also the things that make money for the company.

It's hard to do well! I'm not belittling the job of the IT department. The problem is that a lot of IT guys simply give up because it's too hard. They see that keeping the facilities working is on their job description while bringing in money is on other people's job descriptions, so they only worry about the first. If your goals are incompatible with their ideals for the network, that's your problem, they say.

More IT guys need to realize that a perfectly smooth-running network which is not used to generate revenue is just as bad as a network which is broken beyond all utility.

A switch plugged into a conference room network port for a few hours isn't going to destroy anything. These people need more ports, either accept their perfectly workable ad-hoc solution or come up with something better. "No" is not an option.

Re:People misunderstanding the question...

[malraz]

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.

Professional IT staff are exposed to deadly levels of the stupido-quark which has been known to cause bitterness and vitriol in those exposed. In rare cases this quark will cause the complete meltdown of exposed staffers resulting in formatted drives and the cussing out of CEO's. It is an epidemic that is unsung and for your contribution of a dollar a day you can save the career of the disenfranchised IT worker.

Re:People misunderstanding the question...

[Starteck81]

I wish I had mod points I could give you. That was pretty much a perfect summation of the way any good IT admin should act and feel.

I can't tell you how many times I had to do a search of 15,000 SQ foot lab floor because some aerospace engineer thought it would be a good idea to plug the private network side of SOHO router into the main network. They just couldn't seem to understand why an rogue DHCP server would be a problem.

Re:People misunderstanding the question...

[Anonymous Coward]

Who brags about having zero security breeches on a crypto thread on slashdot? you have serious balls man.

Re:People misunderstanding the question...

[afidel]

Yeah, it's more because we have experience with people breaking things and us getting the blame. As an example at a previous employer we had a CEO with ADD, while sitting in a meeting in our training room he got fidgety and plugged the patch cable from one seat into the popup port at another seat. This caused a loop which brought down the entire C-row of the company. Luckily we used good switches so the problem was recognized by all the other switches and they stopped talking to the one that was going crazy thus saving the rest of the company, but until I figured out what the problem was I had 5 very angry executives yelling at me because they couldn't work.

Re:People misunderstanding the question...

[Agar]

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.

Re:People misunderstanding the question...

[Shadow99_1]

I think you hit the real reason why network admins get bitter... Incompetent (in IT/networking) business management and (typically) low budgets. I know they are the reason why I get bitter at my users...

Hence "Yes I'd love to fix 'problem X', however management has promised three times to give me what we need to fix that and they never come through.", response "But you should be able to fix X anyways! Your good with those server thingies!" The actually reason doesn't much matter, but I've had this very talk three times today... 'Problem X' requires a File server that was not struck by lightning 3 years ago when it was brand new (& before I was ever employed here). I've argued that it needs replaced for 2 years due to intermittent hardware issues from the strike. I absolutely can't get management to care because it hasn't failed yet (& taken all their data with it). It's been 6 months since that server could even run backup software to copy their critical business data to the NAS, a tape drive, or even a darn external hard drive without errors... You'd think someone else would care, but apparently not.... & the day it fails I'll most likely loose my job as they will blame everything on me....

No, I'm not bitter... Why would I be bitter...?

btw, the IT market here where I live is absolutely horrible... If I could find another job, I'd have long since left and let some other poor smuck deal with this... & sadly for me, I have no nest egg to move elsewhere where their are more (& hopefully better) jobs.

Re:People misunderstanding the question...

[hesaigo999ca]

Is it possible that you only really needed one dedicated shared partition to be encryptefor those special files, but tell everyone that nothing goes in without consent...making sure that was is in there is inventoried so as to know its worth as well as control who puts what in there, this would bring down the size of encrypted storage needed no?

Re:People misunderstanding the question...

[turbidostato]

"These people need more ports, either accept their perfectly workable ad-hoc solution or come up with something better. "No" is not an option."

Sorry, but this is a "No" per definition. I'll surely accept their request for "six people need to be connected to Internet by tomorrow at 6AM", even if it's 8PM now, as long as I know there's a fair chance they really couldn't tell me any sooner. But I'll never NEVER will accept an "I will plug a network switch here". *I* am the one that takes the technical decisions (since *I* will be the one at stake by the results of such decisions no matter if I did them or not). It might seem rude and when talking to a polite person when we both have enough time (a very rare concatenation of events) I'll certainly will explain where the policy comes from (which is from experience, politeness, hurryness, risk control and money) but the end result will just stand as hard as in the very beginning: I might ask accountancy for more founds if I feel I need them but I'd never dare to tell them (even worse: to *impose* them) how the accountability book should be managed; I'd might talk to a marketing guy and offer my opinion about how to focus his work when it implies technical aspects (or I even will ask for counsel about how to market my work onto a given internal target) but I wouldn't dare to tell them (even worse: to *impose* them) how our products should be marketed... and the same stays true for the rest of the company; I respect their work and I know the symbiose of our different abilities and strenghs is what makes the company go beyond the mere aggregation of people numbers.

Is it *really* so difficult to understand that the same holds true for the "IT guys" (desktop, servers, applications, networking...) too? That *maybe* there's a no less motivated reason for our behaviour regarding our professional abilities and responsibilites than their very own regarding theirs? That *maybe* even if they are as technically aware on my responsibility realm as myself (which is by itself quite a brave opinion) *I* will know better than them the peculiarities of our environment if only because I expend my duty hours on that just as they expend their hours on theirs? It's so hard to understand that just like they don't explain to me all the boring and excruciating details about their own jobs I *might* be not telling them all the boring and excruciating details about mine in order to not wasting both their time and mine and not boring them but that doesn't mean those excruciating and boring details don't exist? Specifically, aren't they able to understand that since the company pay me some good dollars for my work, managing an IT corporate environment *might* hide some dificulties not found on their home PC and their home network that maybe they didn't consider or else, probably, the company wouldn't extend me all those checks?

Food for mind. Just as Aretha Franklin said, it all goes down to RESPECT.

Re:People misunderstanding the question...

[Mr. Protocol]

Which, of course, only means that when security and necessary accomplishment collide, you're the one who never finds out about it. Ever. There is no compromise.

Re:People misunderstanding the question...

[Bigjeff5]

A switch plugged into a conference room network port for a few hours isn't going to destroy anything.

Actually, too many switches can very well bring down the network, even if they are only temporarily plugged in. Usually this only happens because the networking department is completely incompetant, but it can also happen when a company is growing faster than the IT department is prepared for, or if management is too tight and unwilling to pay for the proper infrastructure, and compromises end up being made to "make things work" for the users, despite the potential hazards to the network.

This happened to Beth-Israel hospital (http://www.cio.com/article/31701/Halamka_on_Beth_Israel_s_Health_Care_IT_Disaster?page=1) a few years ago, when they were aquiring and partnering with hospitals left and right. One day, the network crashed.

It took about four days to get seven hospitals back on-line.

It ended up being a massive Spanning-Tree loop that nobody saw coming. The root cause of spanning-tree loops? Basically, too many switches. In this case a researcher had dumped a bunch of data from a connection that was 10 hops from the nearest router.

The -exact- same thing can happen if your network is stretched to its limits and some numb-nuts of a user thinks he's smart and adds a switch to a conferance room and starts dumping - or pulling - a lot of data. If the connection from the conferance room is 9 hops from the nearest router, and you add that 10th, you very well may bring down the whole network. Chances are if your network is stretched like that, then management isn't forking out the cash for the nice switches that can detect an STP loop and mitigate it, but even if they do, your conferance room switch won't work once you cause an STP loop anyway, so why mess with it?

Why not, instead of thinking you know shit you don't, you let the guys who do this stuff for a living do their job, eh?

By the way, fixing that in 4 days cost something on the order of $100-200k in equipment, and probably that much or more in manpower, just to fix a problem caused by too many switches. The final overhaul on the IT network (which, granted, was absolutely necessary) was something on the order of $3mil.

So you might want to think twice the next time you think you're being clever and plugging crap into the network that you shouldn't be. You may very well shut down the entire corporate network by doing so.

Re:People misunderstanding the question...

[dal20402]

If you never get modded "flamebait," then your opinions are boring. Don't take it so personally.

To stay marginally ontopic, I have the opposite problem from most of the users on this thread. My company's IT department has standout customer service skills and loves to help. But with the exception of the actual IT manager, who is way overstretched and can't do everything, their technical skills don't match up with their service skills.

Re:People misunderstanding the question...

[Fulcrum of Evil]

Ahh, I see. This policy applies only to labs dealing with human genomes and other patient data. We'll leave you alone.

Re:People misunderstanding the question...

[jacks0n]

...So I went down to the tool crib the other day and asked for a pair of 45degree non-magnetic smooth-grip needle nose pliers and George hands me a straight, magnetic, textured tip needle nosed pliers and tells me it's the new corporate standard.

Now, I like George, and I'm a fan of having a tool crib; I don't know what it is, but there's something about me coming up and 'asking' for things periodically with him on his ass all day reading slashdot that makes him think he's my boss. He's confused, the poor bugger, thinks his tool-crib IS the company. Thinks I'm actually 'asking', not just being polite.

Nothing you can do with your tool crib guy once he develops that particular neurosis. Fire him and hire a new one out of school, I guess. I mean, I suppose you could pervert your whole company for the convenience of the tool room, but that would be a laughable farce.

Re:People misunderstanding the question...

[Kent Recal]

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).

But it's not hard to do at all *when* you're an idiot. I can't count the number of times someone plugged both ends of a cat5-cable into the switch...

Re:People misunderstanding the question...

[Free the Cowards]

Of course you don't get to dictate terms to the marketing guys. You're in IT! Why would you be the one dictating? However you'd better be damned sure that the people who actually make whatever product you sell get to dictate terms to the marketing guys. (That is, assuming your company is competent and is not some Dilbert-esque horror.)

The purpose of a company is to make money and it does this by selling products. Any part of the company that is not involved in creating and selling those products is involved in facilitating their creation or their sales.

This is the key point: your job is not to run the network. Your job is to facilitate the people in your company who actually bring in money. That you do this by running the network is secondary. So many IT people think that running the network is all they do and when presented with a choice between helping the rest of the company or protecting the network, they will always choose the latter. Wrong choice!

Re:People misunderstanding the question...

[Free the Cowards]

If the IT guys say "normally this would be fine, but our network is stretched to the limits and this could very well bring it down" then that's fine.

But 99% of the time they do not say this. They simply say "no" and give no reason. Generally it's because they have no reason.

Instances such as you cite are the exception, not the rule. If IT can't provide the requested service then fine, it can't be done. But so much if the time IT simply refuses to work with people because it's something out of their control or beyond whatever mindless policies they have in place.

Re:People misunderstanding the question...

[this great guy]

Your datapoint is irrelevant. Because today's processors are much faster and because the cipher implementations have been improved, it is now much less costlier to encrypt data. Here are some "openssl speed" benchmarks of the RC4 symmetric cipher on a current processor and one released 8 years ago with a version of OpenSSL almost as old:

• 32-bit OpenSSL 0.9.8e (Feb 2007), quad-core 1.9 GHz Opteron 2347: 1024 MByte/s (256 MB/s/core)
• 32-bit OpenSSL 0.9.6e (Jul 2002), single-core 1 GHz Athlon: 60 MByte/s

This is a 17x improvement in performance ! Run the quad-core processor in 64-bit mode and it would probably be 20x faster. By comparison, disk throughput has increased by only about 2x over the last 8 years (50 MB/s vs. 100 MB/s). So run the same test today but replace your 8 Xeon 800 MHz with 8 quad-core processors with 12 disks and you should see almost no speed decrease caused by a well-designed disk encryption app (I can vouch for dm-crypt).

Re:People misunderstanding the question...

[1lus10n]

For the record: Keeping the network healthy is what enables THE VAST MAJORITY of users to do their job.

If you think IT should account for every possible want you can generate then I suggest you prepare to sacrifice some of your budget and headcount to accommodate it. It also might be worth getting rid of the useless twats who are managers in 90+% of the IT shops out there.

Re:People misunderstanding the question...

[Free the Cowards]

For the record: Keeping the network healthy is what enables THE VAST MAJORITY of users to do their job.

Completely true. But at the same time, the vast majority of "abuses" actually don't harm anything. If a wacky request won't actually do any damage then it shouldn't be rejected just because the IT department is uncomfortable with it. Unfortunately this is often what happens.

Another post in this thread captured this attitude perfectly. It said that hooking up a switch was problematic because there was no way to control the individual computers. So if one of them started misbehaving, the only remedy would be to shut off that network drop, thereby disconnecting all of them.

Somehow this was considered to be worse than having them all start out disconnected.

If something will legitimately do damage to your network then certainly you shouldn't let it on (unless the company will go under without it or something of similar magnitude). But a lot of IT policies go far beyond this and impede business for no legitimate reason.

Re:People misunderstanding the question...

[1lus10n]

A properly configured switch on a network that is configured to support it will not have an impact.

That implies:
1. IT was allowed to buy proper gear.
2. IT employed the right people to configure said gear.
3. The office was designed with this purpose in mind.
4. The user follows the assumably documented proceedures.

or
5. You asked and there was adequate time and/or gear to support the request.

On the other hand the outright rejection of your request implies:
1. IT didnt have the budget to buy the right gear.
2. IT doesnt have the right staff.
3. Nobody told IT that this conference room or office should be supporting this purpose. (also see #1)
4. You didnt listen.
5. You were "that guy" - you know, the one who assumes his problem is the only one, his department is more important etc etc. Namely the loud asshole that everyone hates.

Or
6. They simply didnt have time.

Re:People misunderstanding the question...

[1lus10n]

Your job is to help the company make money.

Thats the description of everyone who is employed by every for profit company in the world. Period. Sales wench's are no exception.

Given that statement - your belief that somehow your situation is the only one that matters is laughable. Next time you decide to criticize them perhaps you might want to consider applying for a job in IT. Its good pay for something that you clearly view as being easy, perhaps even trivial.

Re:People misunderstanding the question...

[Free the Cowards]

Don't know why you think this is "my" situation. I'm a programmer, not a salesman. I never see conference rooms or deal with IT anymore. In my past lives I've been the IT guy far more frequently than I've been on the receiving end IT policy.

Re:People misunderstanding the question...

[Anonymous Coward]

Sorry you're cynical; perhaps you should metamod more?

Rest assured that at least some mods care about the principles of moderation. I find myself writing long AC posts in response to people that I take issue with; I consider it a consequence of respect. In your posts I see evidence of a man of forceful character, technical aptitude, and high intellect. I also see a man with little patience, particularly for fools, and an unfortunate lack of civility. If we are to believe your statements, then clearly you have both remarkable knowledge and a valuable perspective on technology that would be of great benefit to the /. community.

It is certainly the fact that slashdot has been taken over by children since you were away; it will continue to be taken over by children in successive days to come until the unforeseeable future. This is not something to be hated and feared, for indeed it is inevitable. Our sages decline and new minds come into flower, in the great cycle that has existed since the Beginning. Cooperation between these different Ages of Man should then be what we seek: how else does the youth determine what is good and right, save by the instruction of his elders? How else is the elder's knowledge refreshed, save by the influx of youthful ideas and enthusiasm?

As a youth to an elder, I would hope that you would keep fast to your morals, and remain an active part of this community. You can be a bastion of principle here, if you choose. It is likely to be a thankless battle, as well as endless, and possibly fruitless. But I believe that you would improve us all if you did.

Yours
-T

Re:People misunderstanding the question...

[turbidostato]

"The purpose of a company is to make money and it does this by selling products."

Quite an interesting example of what I was talking about. There're are MBAs, CxOs, marketing experts, BI experts, dozens of roles that compose a company, specifically on just the side of what a company should do to become profitable but then, it is a programmer the one that really knows what everything is reduced to.

Of course...

"Your job is to facilitate the people in your company who actually bring in money."

those kinds of selfproclaimed experts tend to make embarrasing mistakes of judgement like the previous one. I probably could go for hours, but maybe a clear example can bring some ligth to this issue:

Let's take a "typical" developed company with about a 60% of its expenditure on running operations and a net benefit of about 15%. Let's take a "typical" project-like event which means a 10% of the overall gross income (that's probably an above-average project, but that's to give some advantage to the "bringing money" side). Now, just for make the numbers easier, let's imagine the gross anual income for our example company are 100M.

This means that about 85M is its overall costs of operations, with 85*0.6=51M being its structural costs of operations. Now: the CEO can ask for "absolute" commitment from IT towards the marketing team, so the gross benefit increases 15%". That means that our example sell goes from 10M to 11.5M which certainly is quite a pretty sum that surely will increase our marketing hero's bonuses (but probably not the IT guy's bonuses even when it was his commitment what made for the better profits). Or, at at 15% average net benefit, such a project will go from 100.000 to 115.000 of net benefit. Or, 1.150.000 at the end of the year. All well and good.

BUT: the CEO can ask for a better managed IT environment so to rise savings on operations for a meagre 5% (please consider: 15% on the first scenario against 5% in the second one) by avoiding those "I said I plug the switch and so I'll do, damn your f* spanning tree whatever that means. I'm the guy that brings the money, you bastard IT monkey!" Since those guys make for 34M of expenditures (again in order to make them a favour I'll only find savings on their direct expenditure, without considering structural costs) that will mean (85-51)*0.05=1.7M.

SO: You can put your "selling stars" on a gold altar so to earn 1.15M OR you can listen to your "ever saying NO, even when you don't bring a dime to the company" IT guy and make 1.7M without even increasing your sales by a single dollar (and you can bet that by having a dependable IT environment your sales will increase anyway).

Your choice.

Re:People misunderstanding the question...

[Free the Cowards]

I do so enjoy it when people just pull numbers out of thin air to make their point....

Re:People misunderstanding the question...

[the_B0fh]

Haven't you heard of VMs where the systems run faster in a VM than on the metal? It actually happens especially if the VM has a better disk caching mechanism than the system in the VM.

Re:Encryption is good for security, bad for perfor

[WK2]

Mostly personal observation. I am not using truecrypt, and I only have one core. On my machine, my encrypted drive is about 20% slower than my regular drive. I have done timed trials. I read 50% some time ago, but had never seen that big of a hit, so I that's why I said "up to" 50%.

Re:Encryption is good for security, bad for perfor

[discord5]

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.

Encryption Experiences

[ConallB]

Very often it is management responding to outside influences such as bad press or legislation that prompt the implimentation of whole disk encryption security. No sane IT department takes on the responsibility of whole disk encryption across the whole IT inventory without good reason or suitable resources and funding.

Exceptions can be made for individuals but if you are looking after a sizeable IT inventory it becomes prohibitively expensive to manage security on a case by case basis.

Excellent products, like truecrypt, are designed for personal workstations and lack the enterprise management tools you need when performing mass rollouts and configurations not to mention future management of passwords and data recovery requests. Thats why PGP has become an industry standard.

The marginal loss of performance experienced by the encryption overhead both in termas of performance and hassle of management needs to be offset against the organisations requirments for encryption to comply with legislation or to counter corporate espionage.

If only people were trustworthy and the world was a nicer place then we wouldnt need it at all but to quote Gunnery Sgt. Hartmann "If assholes like you didnt leave footlockers unlocked there would be no thievery!" (Not verbatim, I know, but apt!)

Re:Encryption is good for security, bad for perfor

[IWannaBeAnAC]

I wasn't even talking about desktops though, I was talking about compute servers! I have used a few clusters at LANL, and yeah they have separate classified and unclassified machines (or sometimes, sections of machines) that are partitioned off for classified work, but even the classified part never (as far as I know) uses whole-disk encryption. The original question specifically said that they were intending to encrypt their servers as well.

Re:Encryption is good for security, bad for perfor

[TGoddard]

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.

To defy PGP encryption ...

[VincenzoRomano]

It's just enough to forget to destroy a data printout!
Security in companies and institutes is also in procedures, as encrypted data will eventually get unencrypted for work. From there on poorly designed procedures will defy the encryption.

My company did this and it sucks for performance

[ACK!!]

My windows work laptop went from a fast little Duo Core fairly recent Dell which was quick but felt pretty damn cheap to a complete slow dog.

Not sure if its the software my company used or if its the disk IO overhead or what.

I do know after encrypting my entire disk I now get the PGP login screen immediately after the CMOS screen and before the Windows loader. No Problem.

The real problem is after that. The minute Windows loads up the disk starts churning and barely ever stops.

It just churns and churns and that little hd light just keeps going and going.

And everything just slows right down after that. Oh yes I am not the only one saying this either. Almost everyone reporting the same sort of results.

I actually thought it was a good idea - considering the amount of travel many deployment personnel in my company commit to in a year.

But do your research.

Try out whatever solution with your heavy hitting power users.

Don't settle for security that hampers performance.

What!!??

[ThePhilips]

[...] 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.

What you mean they care not or usability"?????

What about the nice view on crematorium out of your safe and secure cell??? with the nice blue smoke of burning bodies of idiots who doubted guards abilities????? That high electrified barbed wire fence looks sooo sexy in the night under lights of nazi guards' lights. And in the concentration camp they also allow you whooping five(!!!) minute walk!!!!!

What could be better that be safe and under watchful eye of trained professionals???

P.S. On serious side though, you might have not found any sensible articles on PGP whole disk thing because nobody uses it. I knew couple of people in past who for that whole purpose were installing Linux. Yet, their setup was much much more saner: standard Linux setup (bunch of normal partitions) + encrypted partition for sensitive documents and /tmp + disabled swap (lots of memory was installed on the notebook specifically for the purpose).

Encryption != Security

[segedunum]

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.

Re:Encryption != Security

[Growlor]

Neither is locking your the door to your house/car the same as security. Its still a bad idea not to do it though.

Re:Encryption is good for security, bad for perfor

[somersault]

I use hard and soft becaues I'm just tinfoil like that. Don't even have anything to hide either, just like my privacy.

So you take a fairly large disk performance hit - and even lose some CPU time - for absolutely no reason? That's possibly the most cleverest thing I've heard all year.

Are you actually the guy mentioned in the summary who is forcing all these computationally intensive research departments to encrypt their disks for no reason?

Re:Encryption is good for security, bad for perfor

[amorsen]

Which hardware RAID did you pick? Did you avoid RAID 5?

Most built-in (PCI-X, PCI-E etc) SAS/SCSI RAID solutions are completely useless for RAID 5.

Re:Encryption is good for security, bad for perfor

[calmofthestorm]

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.

Re:feel-good actions

[Kjella]

in these type of departments all the computer are on all the time anyways and whole-disk encryption is 100% vulnerable to hard-boot attacks. It may be remotely useful on laptops but for desktops its entirely useless

First of all, I have no idea what a "hard-boot attack" is since there's exactly ONE hit on google for that phrase, your post. Secondly, there's no reason to assume criminals are smart and/or particularly interested in your data. If their department doesn't deal with patient data, if there's no expensive medical equipment directly on site you're probably talking about a rather average office environment with that level of security. Certainly not past anyone breaking in just for stealing the hardware and anything else that might be lying about. What you want to stop is that they sell it to someone with a clue who'll extract it or that they just sell it to some random dude which then finds confidential information and raises a big stink. Hell, even if they think they're stealing it because it has valuable data and they don't know how they end up with just the hardware. It's like with most other security measures, it's not perfect but there's no reason to make it easy.

Use Truecrypt

[undeaddemon]

Have your IT guys evaluate TrueCrypt. I've been using it for some time, and have collegues using it as well, without a negative experience to report.

Re:Use Truecrypt

[Anonymous Coward]

My 2 GHz Pentium M laptop suffers a severe performance impact from a LUKS AES encryption which I use for internal disks and on external USB disks, and the worst thing is that it becomes 'choppy' during large data transfers, meaning the machine freezes every few seconds when copying from encrypted USB disk to another encrypted USB disk. On single-disk transfers, the machine manages 25 MB/s without encryption, with a very low load, i.e., the CPU is still mainly free to be used for computing, but only 16 MB/s with encryption + very high load and choppiness. Copying from one disk to the other degrades from 25 MB/s to only 10 MB/s.

When using the disks normally for working, this is no problem, however. There's only a problem when transfering high amounts of data to/from the disk. So it depends entirely on your disk usage, of course.

My 3 GHz Core2Duo, on the other hand, does not even seem to notice that disk encrytion is used: no performance impact at all, so it seems. I am sure I could find some degradation when doing precise measuring, but it is not normally noticible when working on the machine. With or without encryption, the machine manages ~30MB/s to/from USB. And 35MB/s is the max. you'd ever get out of a very good USB disk today.

Re:Encryption is good for security, bad for perfor

[gr8dude]

A coldboot attack is trivial on paper and in a controlled environment, but not in real world scenarios.

First you need to get hold of an unattended machine that works and the disks are mounted. You can minimize the probability of that by enforcing certain policies such as never leaving the machine unsupervised, closing access to the computer's case or even locking the case, etc.

Trust me, cold boot attacks are not the greatest concern.

FileVault

[Anonymous Coward]

Problem solved. That will be $1000.

Re:Encryption is good for security, bad for perfor

[jlarocco]

That is interesting - if the overhead was really 1%, then why even bother with optimizations for multi cores?

Because then the overhead would be even less than 1%? Seems fairly obvious to me. Some of us actually like our brand new machines to run faster than the machines being replaced. Go figure.

Get over it

[Anonymous Coward]

Patient information legally obligates you to care for it and the risk of loosing a single disk can run into the 10 to 100's of millions....really.

Encrypt it and get over it. You need to be a better steward of information that people have entrusted you with, I don't care if it takes you 5% longer. It reckless thinking like this in the industry that give many a bad name. So what have you done lately to protect personal information?

No that's not a problem

[emj]

Read the FAQ; drives usually have larger block sizes than the block size used for encryption, so there is not much difference.

Re:No that's not a problem

[CopaceticOpus]

Thank you! Your answer was very helpful.

Re:No that's not a problem

[emj]

I live to serve

Re:Encryption is good for security, bad for perfor

[volxdragon]

Nothing is done in "zero time" - the overall average throughput may be the same, but LATENCY for a specific request will go up. This is the same for networking gear...

Re:Encryption is good for security, bad for perfor

[somersault]

Ah, well in that case you do have things to keep private (passwords and financial information), so I don't consider that too much of a waste.

I don't have financial information or other especially private documents on my machine, but I do have stuff like saved firefox and VPN passwords which I wouldn't want getting into the wrong hands. I'm not sure that encrypting the disk would provide much extra protection over the encryption that is already there on the FireFox and OSX keychain password files though. If someone can crack those, they could probably get past disk encryption too (unless there are known weaknesses in the OSX keychain or Firefox master password systems). To me it makes much more sense that work data be encrypted more than my music or *ahem* picture collections, but there are an extremely limited set of people who would find my work related source code in any way interesting or useful.

Security ALL

[8400_RPM]

PGP is the gold standard for whole disk encryption. Encrypting your entire hard drive wasn't really even possible a few years ago. PGP is leading the way. You cry about a few things like compression. Are you serious?!?!? You compress your hard drive? Why not buy a bigger one??? You want multiple partitions so you can boot linux. Sure, you can do that.

But what it all comes down to is:
Security > ALL.
Learn it, know it, love it.

Re:Encryption is good for security, bad for perfor

[IWannaBeAnAC]

Well, OK, but an overhead of 1% is hardly measurable to begin with. If you run it on a dual core machine and halve the overhead, the additional speedup is 1.01 / 1.005 = 1.005. Is it a good investment, to buy a second CPU core to get 0.5 of one percent improvement?

They fight each-other, so you get expanded compres

[Anonymous Coward]

expanded compression.

It's a bit like using zip on a bz2 archive: double the computation, but reduced compression, aka expansion.

Re:feel-good actions

[bard]

I suspect that what he's talking about is the "Cold-Boot" attack, where a running computer is switched off (or maybe using the HW-reset switch) a very short time and then rebooted from a USB stick which dumps all memory to disk where you can still read everything. The memory dump is then analyzed to find encryption keys.

The only disk encryption software I have experience of (Check Point Full Disk Encryption (previously Pointsec for PC)) includes protection against that attack. I expect truecrypt and PGP does too though.

Why not hardware encyrption?

[Zashi]

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.

No difference between encrypted and unencrypted

[Anonymous Coward]

The drive is encrypted by a symmetric block cipher, which means you have blocks of data (typically 128 bits). So, unless you can recover to that resolution, losing the data within that cipher block means you lose that size of chunk of data. Depending on the type of file, you may lose important header information and end up losing that file, but that's no different than in an unencrypted file system.

The only thing you need to be careful of is backup of the volume header. If that isn't backed up and somehow gets corrupted, or it can't be restored, then you'll lose your information. From a pure probability perspective, this is pretty remote.

HPC and encryption

[Pip]

I've never heard of any HPC computer using disk encryption. Though compute intensive work need not be I/O intensive, it might very well be. If there is a real need to keep your data secure in your HPC environment, other measures that encryption are just as effective.

Frankly, encrypting everything is just not the best solution. Especially since encryption doesn't prevent legitimate users of making copies on non-encrypted media and loosing those. I guess your IT staff just found a cool new toy, but well, I don't see any traces of procedures to help safeguard the data.

My word of advice: get a security-officer to define proper procedures for data classification and data handling, really, all you need is procedure and well then maybe, pgp whole disk will play part in implementing a proper data handling procedure for data classified as C=extremely high.

Re:Security ALL

[timmarhy]

compression is going to give you just as big of a performance hit as the encryption. i'd say negotiate with your IT department for more HD's and a faster raid arrangement. that way you can ditch the compression and maybe get a performance boost out of it.

i don't agree with security > all either. it's a trade off. personally i think encrypting ALL your desktops hd's a fucked idea with no merit at all. why not just encrypt all laptops since they are the real danger, leaving site etc, and enforce a policy of destroying all hd's after their use by date.

Tradeoff

[Anonymous Coward]

The place I work uses Pointsec, not PGP, but it's a whole-disk encryption product that competes with it, so the products are similar.

Anyways, the point of my post is that you're being unreasonable. The data on those PCs is important to the company, regardless of whether there are obvious sensitive things on it like social security numbers. If a direct competitor of your company got ahold of one of those PCs, I'm sure your upper management would not be thrilled if it was not encrypted, even though you personally don't think the value of the data is high.

Besides, I'm sure your PC isn't a bleeding edge box, so ask IT for an upgrade to offset the marginal performance hit. If you require as much computing power as you claim, I'm sure they'd be willing to help you out rather than not encrypt it.

Re:Encryption is good for security, bad for perfor

[dissipative_struct]

If they have clusters that are processing classified data then those clusters can only be accessed from classified terminals which are physically controlled. I don't believe it's possible to partition a "section" of an unclassified machine to do classified processing. If classified machines are talking across an unclassified network then they've got Type 1 encryption devices sitting in between them and the network. Protecting classified resources is completely different than protecting unclassified resources since there's already mandatory physical security around classified machines.

delay tactics...

[smoon]

whole disk encryption as a class generally works OK but opens a whole new set of problems; MBR corruption might mean you lose the whole disk; performance overhead is NOT going to be 1% (unless you do virtually no I/O) but the 10-30% that it will be is usually a good tradeoff vs. the confidential data you're trying to protect.

The real reason for the policy is that should a hard drive/laptop/whatever be lost, if it's encrypted no notification is required by law. If it's not encrypted, then you need to prove that the drive didn't contain any PII, which is hard to do since it's no longer available for forensic evaluation.

I suggest you ensure you application is decidedly incompatible with PGP whole disk (BSD? Oddball version of Linux? Custom library in your code that crashes the computer when it detects PGP?) so the IT dept simply can't ram it down your throat. This will buy time, perhaps until hardware mfg's have hardware-level encryption that eliminates the unfortunate performance and compatibility aspects of whole disk encryption.

PS: I've looked at whole disk encryption from a variety of vendors including utimaco, pointsec, and pgp -- they all pretty much work, but assume a generic windows PC running generic apps. Once you move out of that I suspect their support will thin out quickly and IT will abandon the effort.

Re:Encryption is good for security, bad for perfor

[TheRaven64]

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.

Re:Encryption is good for security, bad for perfor

[IWannaBeAnAC]

You obviously never used any of the big DoD supercomputers. Have a look at the (old, by now) ASCI Red configuration here. It has two interfaces, one for classified jobs and one for non-classified jobs.

Here's a disadvantage: recovery

[cheros]

If there is one HUGE problem with whole disk encryption it is recovery from disk failure. I'm not talking about your average Windows crash, PGP whole disk crypto is OK with that. I'm talking about a more massive failure which makes a mess of the NTFS indexing (Windows can do that too).

Normally, you have three options:

- restart and pretend you don't have a problem. Rather hard if you're missing a lot of files :-).

- permit CHKDSK to clean up the disk. In my experience that is a sure way to guarantee you will never be able to access your files in a sensible state ever again. No idea why, but Microsoft doesn't appear to have focused on file recovery with CHKDSK, more on returning the disk to a consistent state. Or maybe I need to do some RTFM :-)

- use another tool to access the disk which doesn't need a 100% clean NTFS layout to still scrape the files off. This can be typically done with a Linux live CD as the read-only NTFS mount of Linux is substantially less picky about how consistent the file system is. I introduced this idea to a large consultancy when I worked there and they have saved a good amount of data this way over the years.

When you use full disk crypto, forget about booting up another OS to recover data. Installing full disk crypto without adding a good backup solution (encrypted, of course) is asking for trouble.

What I like about PGP is the ability to use additional keys which are split, so you need to involve multiple people before you can backdoor it. However, it always makes me wonder if there isn't an additional key of which we don't know anything..

Re:Here's a disadvantage: recovery

[Agar]

FYI, PGP WDE fully supports WinPE, BartPE, and Windows Recovery Console.

If you need to recover, you can build a BartPE disk with the tools you need, boot from it, authenticate to the corrupted drive, and fully access it for repair or scraping off the data as needed. It's pretty cool.

Regarding an "additional key" -- there's none. Source code is available on the PGP website, and it gets downloaded frequently for crypto review. ...Yes, I work for PGP.

Re:Here's a disadvantage: recovery

[cheros]

Interesting, time to do some testing - good to know. However, this approach doesn't address my primary reservation (although I admittedly didn't express it that well): you will need Windows to repair Windows, and from my experience that is not the optimum solution when it has affected the file system.

I would be *extremely* interested in a route where I could boot a Linux live CD and authenticate to an encrypted drive so I could get to the file system for rescue purposes - I wasn't being theoretical here, I have been there. If I have a "translation" slice in between which deals with the crypto side of things it would amount to a solution..

As for the additional key - your assertion that code is public and has been verified lacks a link to evidence that the executables on sale are indeed compiled from that specific source. It would be nice to see a confirmation from an acknowledged independent and competent resource - or maybe you have that and I didn't find it.

Look at the perspective of the average end user - they have no real means to execute such a verification so you need to have such work verified by a trusted independent source (probably foreign to cancel any allegations about NSA sponsorship :-).

BTW, I may appear harsh but if I wasn't happy with what PGP currently provides I wouldn't use it (licensed on all systems that run Windows) - I see the above omissions more as a managed risk :-).

Re:Here's a disadvantage: recovery

[CodeBuster]

The Full Disk Encryption product that I have the most personal experience using, TrueCrypt, mounts the encrypted disk as a virtual partition during the boot loader phase (i.e. before ANY semblance of Windows has loaded). This way, any tools such as CHKDSK remain completely unaware of any encryption that is going on (it is handled by the virtual disk driver at a lower level). From the standpoint of Windows a special driver is being used to access the HDD and that is all that it knows.

Re:Encryption is good for security, bad for perfor

[b4upoo]

This issue deserves some formal testing. For example does OS effect the outcome or how about file system type such as fx3 vs. Reiser? All in all I suspect that the man needs a very specific answer that will require a real test rather than opinions.

overhead for patient research?

[Uzik2]

The overhead for this technology is during retrieving and storing data to the hard disk.
Unless you're running a database server on your personal machine the overhead is negligible.
Unfortunately it's not the security panacea they might think it is. The only thing it protects
you from is public disclosure of data from lost or stolen machines. If the machines are in
a protected access environment and aren't removed is probably a waste of time. It might
make good "security theatre" though. (it will make some people feel better even if it's worthless)

Dedicated hardware

[mikkelm]

Are there any consumer grade hardware cryptography engines to offload the work from your CPU to dedicated hardware? It seems like there'd be a big market for it nowadays.

Let's be clear

[ratboy666]

USE THE CRYPTO

and yes, I'm shouting. This has been resisted for too long -- its kind of like garbage collection in programming systems.

The slow part is the physical drive. The crypto can be done FASTER than the physical drive, which means, at worst, that an additional processor needs to be assigned.

Indeed, the ONLY time I recommend crypto not be used is when dealing with US border. There I use file crypto on specific projects, along with dd to overwrite freespace and swap (before crossing).

But, if everyone (looking at US citizens) starts USING crypto, a fully encrypted laptop would not raise suspicion.

net access more important than encryption

[wikinerd]

Better cut all net access before thinking about encryption. Am I the only one who thinks that a lab working with stone age technologies like paper and pencils is more secure than a lab using computers?

Re:Encryption is good for security, bad for perfor

[jgtg32a]

because .5% overhead is better than 1%
The DoD machines aren't on the internet and I don't think they have any real network access.

Re: Obvious troll

[Anonymous Coward]

This is an obvious troll and should not be modded "interesting".

Sheesh. 1% my a$$.

PGP Co sucks

[Anonymous Coward]

The software sucks. It's glitchy. Their coders don't know what they're doing. I was working for a military contractor and we had the software removed within a month of installing it on everyone's computers.

an answer looking for a question

[v1]

It looks like your admins are the type that if they stumble on a "neat idea", they start looking for ways to use it. Or finding ways to use it. Or inventing ways to use it.

Not a good thing. Sort of a colary to "when all you have is a hammer, everything looks like a nail". Only in this case, "when you find a shiny new hammer, you start looking for nails, or other things that could possibly use some hammering".

Here's hoping they don't continue to push this on you even if you show them it's not a good idea. It's their job to build a case for implementation, not your job to build a case for cancellation. Anyone that says "we're going to do this unless you can show us a very good reason not to" (without having demonstrated a need to press on) needs to be taken into a small private room for a quiet discussion, or a quick beating.

Here's the results of a test on Truecrypt overhead

[weedenbc]

On Episode 133 of Security Now, Steve Gibson does a test to try and calculate the overhead of Truecrypt and comes up with a number in the single percents. The test was to defrag an image with whole disk encryption and without and compare the times.

Transcript:

http://www.grc.com/sn/sn-133.htm

Wow

[Anonymous Coward]

Out of curiosity, do you think that being an asshole somehow makes you cool? That insulting the guy will lend any more credence to your advice or make anybody more likely to listen to you?

Because it won't. It just makes you look like a typical super-nerd elitist who thinks that because some solution is perfectly obvious to him, it should be perfectly obvious to everybody else, too.

People misunderstanding words like 'require'.

[morgan_greywolf]

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.

Re:People misunderstanding words like 'require'.

[Mr. Slippery]

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.

It has limited access - until a larger drive needs to be installed, and the the old one ends up in the spare parts bin and eventually gets sold as surplus, and somebody gets it home and finds your medical records on it.

Or, the service is in a locked room with limited access - but the DVD-Rs with the backups get lost on the way to the off-site storage facility.

Confidential data has been exposed in the past via both of these sorts of scenarios. Yes, perfect physical control would prevent the need for them. But it's a poor sort of security plan that relies on one layer being perfect.

The same reasoning applies to why a lab doing non-sensitive work would be subject to the same controls: it's more reliable to say "X for every server" that to say "X for every server of which it's true that Y and Z". Because Y and Z might not be true on that server today, but will tomorrow. Hardware gets moved around, servers get consolidated.

Re:People misunderstanding words like 'require'.

[morgan_greywolf]

It has limited access - until a larger drive needs to be installed, and the the old one ends up in the spare parts bin and eventually gets sold as surplus, and somebody gets it home and finds your medical records on it.

Standard policy almost everywhere I've worked has been "old disks that aren't being re-used internally get destroyed." And those that ARE getting re-used, don't get to be re-used until they are wiped clean with something like DBAN. Places that do sell off old equipment have also had the same requirement -- old disks get wiped.

Re:People misunderstanding words like 'require'.

[ParanoiaBOTS]

Repeat after me: "The first line of security is physical."

Correct me if I am wrong here (I may be), but to further your point doesn't whole disk encryption protect you in ONLY the case that someone physically steals the hard drive? Thus rendering it useless unless you have a way to decrypt it.

Re:People misunderstanding words like 'require'.

[morgan_greywolf]

You are correct. I didn't say that outright, and maybe I should have, but I did imply that.

Re:People misunderstanding words like 'require'.

[Mr. Slippery]

Places that do sell off old equipment have also had the same requirement -- old disks get wiped.

Yes, that's the theory. The reality is this:

LONDON (AP) -- A computer containing banking security details of more than 1 million people has been sold on eBay for $64, bank officials said Tuesday -- the latest in a series of losses of personal data in the UK.

The computer contained account numbers, passwords, cell phone numbers and signatures. It belonged to MailSource UK -- an arm of Graphic Data, an archiving company that holds financial information for Royal Bank of Scotland, NatWest and American Express.

and this:

Laptops and hard disks containing sensitive corporate data are readily available at auction sites. Researchers paid $10 for a hard disk from eBay which came with access codes to the secure intranet of one of Europe's largest financial services groups.

It was the first of 100 disks and laptops purchased as spare and used parts from internet auction sites as part of a study into the accessibility of information from lost laptops and hard disks.

In the study by security specialists Pointsec Mobile Technologies, seven out of ten of the disks, all of which were supposedly "wiped-clean" or "re-formatted," contained readable information.

and...well, Google "ebay sensitive data" and see.

Fortunately, disk encryption mitigates what could be disasters:

Counter terrorism police are today investigating the discovery of a Home Office laptop and encrypted data disc - apparently bought on eBay. The confidential disc was discovered when the laptop was brought in for servicing. We have a great viewpoint from Brian Spector, an IT content protection expert.

"With the statistics showing that nearly 500 government devices have gone missing since 2001, it was only a matter of time before a confidential disc inadvertently ended up on Ebay. Luckily, the public sector finally seems to be learning from repeated mistakes, as the laptop and disc were encrypted..."- Brian Spector, General Manager for Content Protection Group, Workshare

Re:People misunderstanding words like 'require'.

[hesaigo999ca]

I believe the post mentioned laptops, and not servers...

This is academia?

[Anonymous Coward]

Ya know this sounds more like something a government agency would chose to do not really an academic institute. Are you sure that your characterization of the nature of this decision is accurate?

Re:Encryption is good for security, bad for perfor

[Anonymous Coward]

I don't believe it's possible to partition a "section" of an unclassified machine to do classified processing.

Yes, it is.

Declare it performance critical temporary data

[syousef]

...and get it exempt by demonstrating degraded performance if you use whole disk encryption. If the IT guys complain or tell you you're doing it wrong ask for their help to do it right. Then go ahead and encrypt a few of your documents to keep the IT staff happy. All your "temp data" are belong to YOU. IT guys get to implement their new policy with you as an exception. Then go work on your resume. Everyone's happy!

Re:Encryption is good for security, bad for perfor

[172pilot]

You're "mostly" right.. but, dont forget, there's a difference between throughput and latency... Imagine your garden hose. a 200 foot hose may not slow down the water, and you're still getting the THROUGHPUT that you need (gallons per minute), but the water that comes out of the sprinkler head end may come out 20 seconds after it went into the other end of the hose (20 second latency)... For some jobs, with sequential read/write, throughput may be all you need (and may be where the 1% rating comes from on the original poster's PGP stat) but for something that needs to stop and start, and/or have quick access to random data, waiting for a decryption/encryption engine isn't a good fit, even if it is hardware. -Steve

Re:My company did this and it sucks for performanc

[Growlor]

Something is wrong. I recently evaluated FDE products for my employer (although PGP was not one of them) and other than the initial encryption (which slowed-down my PC about as much as a complete backup would) the performance hit is not noticeable. If you are seeing constant performance hits which seem to be directly related to adding a modern encryption product, then something is very wrong (maybe you have minimal memory and it's try to encrypt the swap file/partition?)

No open source full disk encryption for MacOSX

[ad454]

Unfortunately there does not appear to be any open source full disk encryption options for MacOSX on the primary boot drive. TrueCrypt's MacOSX port does not provide the full-disk encryption support that it provides for its Windows & Linux ports. In fact, on MacOSX, one cannot even use TrueCrypt to encrypt one's home directory, without having to be forced to first log in as another user to mount the TrueCrypt image and remained logged in while the original user is logged into their encrypted home directory on the mounted image.

There are proprietary closed source options for MacOSX full disk encryption, but I would not trust any of them unless I can examine the source and compile it myself.

users and abusers

[rbanffy]

"it is hard to find any negative articles on PGP"

Most probably because it's not common to find it abused in such a stupid way...

"Performance" vs. reliability

[managerialslime]

"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

Re:Encryption is good for security, bad for perfor

[Lord Kano]

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!

The DoD has tanks, fighter-bombers and men with M-16s to keep their servers secure. Encryption isn't as necessary for them.

LK

Some disadvantages?

[CockMonster]

What about the handle leak that will render your machine unusuable if you leave it on overnight? Still waiting for PGP to fix it.

Re:Encryption is good for security, bad for perfor

[calmofthestorm]

You're right, though I'd argue that on top of all the buffering etc going on already you can design such that this isn't the slow step. Also, any data access that needs to be that fast should be on a ramdisk anyway, security or no.

May be a mandate from outside the company...

[Firstoni]

Considering the type of data that the OP is working with and the choice of the product to use, it may be that they fall under the government mandate of using encryption and that it HAS to be FIPS 140-2 approved. In this case TrueCrypt (as much as I like it) is not a valid choice, as it is NOT FIPS 140-2 approved.

Re:Encryption is good for security, bad for perfor

[Anonymous Coward]

Even the US DoD machines that are used for classified research do not do this!

Um...I think they'll have slightly more stringent physical protection applied (big fences, big guards, big guns). That makes up for a lot.

Re:Encryption is good for security, bad for perfor

[rdnetto]

Catch is, USB drives are way slower than hard drives. As in, 2-3 orders of magnitude slower. It could be that the USB is a bigger bottleneck than the encryption.

Re:Encryption is good for security, bad for perfor

[eimsand]

Which cipher did you use?

The AES is actually pretty fast, if you study the algorithm. A lot of bit shifts and XOR operations that can be done very rapidly in hardware.

(I've never benchmarked my own system, so I'm not looking to dispute your figures. Just curious.)

Pilot

[Anonymous Coward]

1. State you concerns in a letter to your manager and the IT department.
2. Measure your current performance
3. Perform a pilot study to compare performance of the PGP solution against your baseline.

Re:Encryption is good for security, bad for perfor

[GoulDuck]

That is interesting - if the overhead was really 1%, then why even bother with optimizations for multi cores?

Why not use the other cores when they are there? :)

My Dualcore T9500 benchmarks at around 170 MB/s with 10 MB test data with TrueCrypt 6 and some programs running. That is both encryption and decryption. Encryption a little faster.

Re:Encryption is good for security, bad for perfor

[Anonymous Coward]

The advantage of hardware encryption is that
1) The encryption doesn't touch CPU or memory resources
2) The encryption can be done in parallel, you write one thing while encrypting the next thing to be written.

I work for Seagate and took an internal course on FDE. The main downside to hardware FDE as security measures is that it doesn't help you at all while the drive is on (the only I/O differences with the devices are you can only write one sector in a commmand, and when you power on the device you must have a password). Once the drive is on, FDE doesn't stop hackers from breaking in. The point is a stolen laptop (that is off) is completely unreadable.

just work with the IT people

[Goldsmith]

At a lab I used to work at, we had problems with IT shutting down communication between various instruments we had because they used "non-standard" ports (they looked like viruses to an automated snooper).

After fighting that for a few years, we just took the whole lab off of the network (no access to school network or internet). We put in a server (managed by the IT people, with all the encryption and security they wanted) which was connected to the school network (and the internet) and to which we could upload data from the lab. Laptops could still be used to access e-mail and the internet, but could not run experiments.

I imagine if you came to your IT people with a plan for good physical security, an explanation of what you're working on and a plan to isolate yourself from any patient data, they would be happy to help you. They're there to make your life easier, not harder.

Ancient citation

[greywalker]

It seems a bit petulant to question an institutional IT policy using reference to an article that's apparently over 10 years old.

From the article (emphasis mine):
"I tested a beta of PGP disk version 1 for Microsoft Corp. Windows95 version 1 in Network Computing's University of Wisconsin lab, installing it on an AMD K6 200-MHz computer with 9 GB of Ultra DMA EIDE drives and 64 MB of SDRAM memory.

As to why full-disk encryption might be required, many states now have data-loss notification laws that require you notify anyone that might be affected unless the drive is completely encrypted. This is the case in my state, though my institution only recommends full-disk encryption on laptops or very high-risk data. The best option to keep sensitive data safe is to keep it on a protected file server in a physically secure, monitored location (i.e. campus data center) rather than on a random local computer in someone's lab; however, this doesn't always work for high-performance analysis. And there's also the "I want my data in my lab so I can hug the server" mindset to deal with in some situations.

Of course, my perspective may be a bit skewed. As a technical policy enforcer at a higher-ed institution, I'm fairly used to hearing a myriad of excuses for why policies, even those based on specific state or federal laws, shouldn't apply to someone's particular academic research context. On average, I've found that faculty arguments against IT policies are as creative and insubstantial as the excuses that their students give for late homework.

Re:Encryption is good for security, bad for perfor

[GoulDuck]

Catch is, USB drives are way slower than hard drives. As in, 2-3 orders of magnitude slower. It could be that the USB is a bigger bottleneck than the encryption.

True. But my tests shows that I am able to pull around 170 MB/s in TrueCrypt benchmark, so the disk will always be the bottleneck.

When developing and testing virtual computers, USB speed is fine.

Re:Encryption is good for security, bad for perfor

[LWATCDR]

Well CPUs have gotten a lot faster in the last few years.
I do wonder with a modern CPU if a hardware RAID is of any use on a NAS server. You can get a Athlon X2 5000 for under $100 and four GB of ram for under $70 these days. Going up to a Xeon or Opteron will cost a bit more but not a lot.
Did you test with RAID5?
Just wondering.

Requirements can specify the means - FIPS 140-2

[Digital_Quartz]

Especially when we're talking about security.

If your requirement is "I need my disks to be encrypted", for example, and your requirements go no further than that, then you may find your vendor of choice decides to encrypt your disk by XORing it with "TheSuperSecretPasskey". Technically encrypted, but not very useful.

Think that's unlikely? That's how some eBook DRM schemes work.

In the US and Canada, there's something called FIPS 140-2 which describes in painful detail exactly what constitutes a "secure system", including what crypto algorithms may be used (right down to the RNGs). The idea is to make it so your typical government employee can distinguish between something that is actually secure, and something which is snake-oil secure, without a doctorate in math.

Likely the requirements in this case are coming from something like HIPAA, which I'm less familiar with, but specifies exactly how patient information should be treated.

Re:Requirements can specify the means - FIPS 140-2

[leuk_he]

Pointing out to the IT helpdesk that they need to implement more security because only-encrypotion is not enough will not help you in preventing you high performance kit to be transformed.

PS, and don't forget to kill anti-virus in the high performance computers. If you think that disk encryption cost a lot of performance, think again, on-access anti-virus-scanning is A LOT more expensive in MY experience.

No problems

[octaene]

I'm a big fan of TrueCrypt, and have used it for about 3 years. In that same time, my company has rolled out PGP Full Disk encryption. Honestly, we've had nothing but positive feedback about how unintrusive the product is. This is easily the security tool with the highest positive employee feedback we've ever deployed, hands down.

Business Needs drive security....

[Anonymous Coward]

What has happened is a shift away from common sense to paranoia. It is and always has been the case that business needs come first, THEN security. The purpose of all the computational power is to support the business need for it in the first place, not the security need. In addition, Risk Management should be used to then decide what, if any, security needs must be met, and only enough to provide adequate security.

Security should never ever trump business needs and security should only be implemented if the risk dictates a threat that can exploit a vulnerability and has a high enough probability of occurance

out of control IT guys

[Thaelon]

When are the IT/network guys going to realize that among their job responsibilities are facilitating and enabling their users, not restricting them in new and inventive ways because it makes them feel useful, or is an excuse to exercise their authority. The job is to make our jobs faster, and easier. Security is secondary to getting the job done. And yes, secondary. Because if the business can't get work done, it doesn't get paid, if it doesn't get paid, it ceases to be rather quickly, and thus you don't have anything to secure.

Re:out of control IT guys

[detubevidste]

"Security is secondary". Okay. How about in the banking world? How about securing a nuclear deterrent? Your generalization goes too far. IT's direct responsibility is as a business enabler. Users are one extremely important part of that, but business requirements vary by industry and project. In many sectors, security requirements are a business requirement, stipulated by customer, regulation, industry standard, or funding source. In these cases security is the prerequisite to the business. Without security, no business, no users. Example: If the lab in question receives grants, or works with human subjects or their data, they must handle the data according to grant or NIH stipulations, or risk losing their funding.

Re:out of control IT guys

[Lord Ender]

Actually, IT answers to management. And management wants to keep the cash cow part of the business working. Management is fine with your job being slower and harder so long as that significantly reduces your chances of destroying part of the business which is much more important than you are.

Sot it would seem you are forgetting who you work for.

Re:Encryption is good for security, bad for perfor

[JoeMerchant]

I find this to be true in Windows networking as well (big linear reads are pretty quick, little chunk access is dog-slow.)

To the parent: in addition to documenting the money/time cost impact of implementing a policy that has no value (beyond standardization) in your department, you can throw a little FUD on the fire: when a standard disk gets corrupted, you lose the corrupted portion, when certain (frequently written) parts of an encrypted partition get corrupted, you can lose the whole partition.

Apple has the option to put a user's whole home partition in a File Vault. I tested this on a MacBook Pro since we were considering implementing a HIPPA sensitive system on OS-X. The MBP had a tendency to not shut down cleanly, especially with the drivers they were circulating in 2006 - it only took about 3 of these unclean shutdowns to hose my encrypted home partition, essentially locking me out of the machine entirely. I knew all the passwords, but the best that escalated AppleCare could come up with was to reformat the drive and start over. I still have the unclean shutdowns, but now (without File Vault) when they cause a little corruption, Disk Doctor cleans it up and I don't have to do a whole system restore. I keep only the sensitive files in File Vault, encrypting the whole drive is too risky for me.

right tool for the right job

[prgrmr]

They should encrypt the network, not the servers. Then you only need to encrypt the laptops and USB sticks and other removable media.

Re:Encryption is good for security, bad for perfor

[discord5]

Which hardware RAID did you pick? Did you avoid RAID 5?

The RAID we tested was RAID-0 and RAID-1. We have several filesystems used only for temporary data which lives about 1 hour (intermediate results between steps) and gets tossed after that (unless we're debugging), so if that crashes it's no big deal. The largest problem for us is that we need to be able to have X TB of diskspace (with X growing every year) that needs to have Y MB/s throughput (with Y growing every year as well). These types of filesystems we usually setup in RAID-0.

With RAID-1 the idea was originally to make sure the operating system disk itself doesn't croak, but in the end we decided to make an install image that can be deployed in a matter half an hour. If a particular fileserver dies we lose at most 1 hour of computing time, and the lost jobs get rescheduled, unless all of those fileservers would die at the same time (that would really make my day).

For long term storage (the actual results and original files) we already have a solution, which I don't have any control over other than an NFS share that I mount. Speed is not really of importance here. From what I gather they do use RAID-5 there, but it's a Fibre Channel SAN that gets exported. Sadly, I didn't get to have fun with that thing since it's an area I'm quite interested in.

I'm really hoping to have some fun with ZFS in the near future. I've been hearing a lot of noise about it and I want to see what it can do for us and if it's a viable solution.

Re:Encryption is good for security, bad for perfor

[owlstead]

Serpent? What the hack are you using Serpent for?

From wikipedia (and my mind):
"Serpent was widely viewed as taking a more conservative approach to security than the other AES finalists, opting for a larger security margin: the designers deemed 16 rounds to be sufficient against known types of attack, but specified 32 rounds as insurance against future discoveries in cryptanalysis."

Rijndael is probably better researched as well, since it became AES (and since nothing is found yet, it's probably more secure). Anyway, for additional security I would stick to AES-256 or just plain AES-128. It's very likely to be much faster and nobody with a serious mind is going to attack the crypto-protocol used (unless it is single DES or something similar).

Anonymous Coward

[Anonymous Coward]

Who's the expert on IT and security requirements and who is the researcher? Let management play their CYA game and stop fighting with IT.

Yes, I'm an IT'er.

Think of it this way. IT is a peripheral support group in most businesses. You can let the hobbiest engineers and scientists play sysadmin and you'll get hobbiest results, if not a turf war between departments. Only management SHOULD be worrying about how security and productivity are balanced. I recommend that the IT manager be a direct report to the highest level of ANY business to prevent abusive control of IT resources.

If you don't like your management, you're working for the wrong business. Let IT do their job. Do you think they like throwing in extra layers of security? That increases their workload exponentially.

Re:Anonymous Coward

[base3]

That increases their workload exponentially.

No, it increases their workload linearly--their budget and power is what increases exponentially. There's money in making management afraid, and eye-tee security charlatans are pretty good at that.

Re:Anonymous Coward

[Anonymous Coward]

And if the security is bought and there's still a compromise, someone's getting a pink slip.

IT is about as binary a job as you can have. Things tend to be seen as working or broke. People who bluff either never paid their dues in the trenches or they don't keep the job long. Otherwise, you're one of those people who probably should be looking for work somewhere where politics isn't job #1.

You're probably basing your conspiracy theories on IT departments who outsource everything to consultants. They're a waste of space anyway.

Accountability has to begin somewhere. I know I've already been sent too many letters from various places recommending that I do a credit check because someone lost some tapes or a laptop.

Re:Anonymous Coward

[base3]

You'd think that . . . but they can just say they followed "best practices" and use the breach to get even *more* budget. Concur about outsourcing to consultants.

Re:Encryption is good for security, bad for perfor

[discord5]

This issue deserves some formal testing. For example does OS effect the outcome or how about file system type such as fx3 vs. Reiser?

FWIW, I've had really good experiences with XFS. For my particular usage XFS came out on top in performance in the areas that matter for our particular usage. We tested Reiser 3, ext2, ext3 and XFS. Again, some filesystems will perform better than others in different circumstances. Note that I'm not saying anything bad about other filesystems, each does what it does and fills its users particular needs.

So yeah, for specific answers especially performance wise, you're best off with googling what other people do and what kind of performance they get, and testing things out for yourself. If performance is critical enough for your application you can justify the time (and money) it takes to test the systems you're considering (within reason).

Linux and PGP?

[Anonymous Coward]

Correct me if I'm wrong, but I believe that Linux is not supported by PGP WDE. It's an easy question of "Do you use Linux?" If you do, then it's a horrible productivity hit because you can no longer use your OS...

Re:Encryption is good for security, bad for perfor

[discord5]

Well CPUs have gotten a lot faster in the last few years.

The linux kernel has advanced since then as well, and storage media as well. If I'd have these statistics handy they'd be an interesting reference, but they'd be hopelessly outdated.

Did you test with RAID5?

No, only RAID-0 and RAID-1. I've replied somewhere in this thread to someone else on the specifics of my type of usage.

Just a thought...

[Serious Poo]

One option to consider is seeing whether you can file for an exception. Your company may have an exception policy with respect to the implementation of controls like full disk encryption. If not, you may want to ask them to implement one as it's a fairly standard practice. The security folks may want you to explain to them (in writing) why you can't implement the control, why you don't believe there's risk, and what possible other mitigating controls exist to minimize or eliminate the risk of not using full disk encryption, but with that you might be able to file for an exception. Just a thought.

Users Are Stupid

[gryf]

Always remember this. I'm not referring to the submitter necessarily, but never put it past the new guy, or the old fart in the corner who should know better to download PII ( Personal Identifying Information ) and forget about it. Then, all it takes is one laptop left in the back of the car and bam! the company has to assume all of the PII is out on the market.

WDE causes me headaches, but I figure the speed of my memory paging isn't as much an issue as the constant paging. Add more memory, stop paging, move on.

Honestly, with Windows, WDE bothers me more because relatively fixable system problems which prevent booting become 'nuke and pave' problems than because it makes the computer slower.

The first time ( or next time ) your PII is lost because some schlub downloaded it against policy and left his laptop at the coffee shop, you'll wish your company had a universal WDE policy.

I'm a Protozoa..

[MancunianMaskMan]

..you insensitive clod.

I don't want my data leaked, thank you very much!

Re:I'm a Protozoa..

[wanax]

Then repeat after me: Stay away from the test tubes!

What does "high-performance computational" _mean_?

[Sloppy]

what are the disadvantages of PGP in terms of performance, Linux, and high-performance computational research?

When you say "high performance computational," I envision CPU-bound number crunching that isn't doing much disk I/O. Thus, the disadvantage would be: none.

If that's not what you're doing (i.e. you're actually talking about a database server that doesn't have enough RAM), then I guess how I could see the disadvantage as being pretty high.

So: what are you doing? What does "high performance computational," actually mean in your context?

Another issue:

Furthermore, there is some evidence that certain forms of compression are also incompatible with PGP whole disk encryption.

That's hard to believe. I won't definitively say your source is wrong, but you should be pretty skeptical about it. You should look really hard at this "evidence" or put it forth for discussion.

That aside, in my opinion, full disk encryption is usually unnecessary overkill, provided that you really know where your data is. Just get /home, swap, probably /var, and maybe /tmp (depending on how you're doing things) and you should be well-covered. There's no reason to encrypt /etc and /usr/bin, for example, so why pay for any overhead there?

Re:Encryption is good for security, bad for perfor

[LWATCDR]

Thanks. I found the post.
RAID 0 and 1 are low CPU use to start with so I would expect good performance with that.
My latest build comes with 5 SATA ports and one ESATA.
If I had all the cash I wanted to spend on this build I would get two raptors and make those RAID1 for the OS and then Three 1TB drives and do a RAID5 for media storage.
Maybe some day.

Re:Encryption is good for security, bad for perfor

[pahoran]

I don't know what "defence-related site" you're working at, but at mine the "Unclassified" network has more security policies attached to it than I've seen in any corporate environment.

The "Classified" network is worse and in most cases it's almost impossible to do actual work there. Of course, the dirty secret is: that's the whole point. What gov. civil servant (be they military or not) wants to do actual work? Also, since everything is "Classified" then it's also very difficult for work to be peer-reviewed so there's no accountability for what's done there.

I swear, half of the stuff we do here must be counterintelligence. We stamp it "sensitive" or "For Official Use Only" -- but if any foreign intelligence agency got their hands on it they'd be laughing so hard they might consider giving up on spying on this country altogether.

biology lessons

[operon]

tell the IT guys that humans are not protozoa

If you were running a Via Nano, AES offloading?

[Calyth]

A quick google for PGP whole disk encryption yield PGP's spec page

Which probably means that the scheme is your typical PGP your symmetric key...

So it seems that an AES acceleration, such as the VIA PadLock, could potentially mitigate the performance issues.
X-bit labs just had a minor blurb recently about how the Via Nano with PadLock trounced the Core 2 Quad...

What joy doth flaming provideth?

[mrraven]

What joy do people derive from flaming? I don't get it... :(

  And yes this is an obvious flame considering since the OP is not working with sensitive data.

Re:Encryption is good for security, bad for perfor

[Sloppy]

My experience is that on 8-year-old processors, software RAID5's overhead is pretty damn minor. I can't imagine how minor it is on today's stuff.

And then, on top of that, disks are getting so huge that RAID5 is on the way out. RAID10 or even RAID1 is the way to go now, so the overhead has gone down even if you ignore processor gains.

Hardware RAID is so obsolete that it just amazes me that it's still around.

Use symmetric crypto not pgp.

[anwyn]

As others have pointed out there are some disadvantages to whole disk encryption. Whole disk encryption does not solve all security problems.

But if in spite of this, you still want to use whole disk encryption, I do not think that PGP is the answer. I think that simple symmetric crypto is a better fit.

PGP's claim to fame is its public key nature. That is it solves the key distribution problem. A sender does not have to contact a receiver to agree on a symmetric key. The receiver can look up the sender's "public key" from published sources.

But in the case of whole disk encryption there is no key distribution problem. All necessary keys must exist at boot time, under any whole disk encryption scheme. Therefore the key distribution problem is solved beforehand by definition.

PGP uses a hybrid solution to the key distribution problem. Public key encryption is used to distribute a symmetric key which is used for the bulk of the work. Since in the case of whole disk encryption there is by definition no key distribution problem, the public key stuff can be eliminated resulting in stronger simpler crypto.

Also, symmetric key disk encryption is available for free (both in the since of beer and freedom) with most Linux distributions.

Re:Use symmetric crypto not pgp.

[synthesizerpatel]

This assumes that you're 'just some guy/gal with a laptop'. The point of PGP Whole Disk encryption is that the IT staff can retain a copy of your key (key escrow) so that if you lose your key or forget your password your data can still be recovered.

What works good for individuals doesn't necessarily work good for enterprises.

That's why PGP costs money and 'oops I forgot my key, bye bye data' solutions do not. Nothing wrong with either method, but there are really strict rules in the US about retaining data related to business decisions, finance, etc.

I'd wager that the drive for encrypting laptops is driven by fiduciary responsibility of which security is simply a subset of rules on managing data. That's who RSA caters to.

Re:Encryption is good for security, bad for perfor

[Blackknight]

ZFS with RAIDZ2 also has almost no overhead, the extra features like on the fly compression are just gravy. I've also seen a lot of hardware RAIDs fail, only had one or two Linux MDs fail that I couldn't rebuild.

Re:Encryption is good for security, bad for perfor

[STrinity]

Among the people who claim this is Steve Gibson who does the Security Now podcast with Leo Laporte. When he benchmarked TrueCrypt, he found that not only was the overhead as low as claimed, but that Windows Defrag ran faster.

I run TrueCrypt on a machine that I use for audio editing, and I've seen no performance dip since installing it -- the boot time remains between 60-90 seconds, even with the password screen.

Re:Encryption is good for security, bad for perfor

[Amazing Quantum Man]

It can cause a hit on battery life, too...

I had a company laptop with whole disk encryption -- required, we had sensitive (unclassified) data on it. The A/V (Symantec Corporate) would hit the disk every 5 seconds, and because it was encrypted, took a bigger hit on the battery. You could hear the CPU fan spin up every 5 seconds or so.

If you're interested, it was actually the "tamper resistance", where it was checking to see that it was itself intact.

Re:Boot block corruption

[Anonymous Coward]

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.

For system partition encryption, TrueCrypt forces you to create an iso which contains the original password hash as well as the original boot sector of the drive. If you can't remember what the end user changed the password to after IT encrypted it or the boot sector goes wonky, just use the disk and you are on your way.

Re:Encryption is good for security, bad for perfor

[Amazing Quantum Man]

Yep. I set that up once -- I wound up being the ISSO. I wonder how many of the posters here have even read NISPOM chapter 8?

We set up a cluster and 3 workstations on a separate network. The network was physically isolated.
Getting the paperwork completed for the DD-254 was a nightmare.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Risk vs Reward

[PrivacyDeath]

alaederach wasn't looking for a sales pitch on Truecrypt. The decision has been made. He is looking to the slashdot community to empower him with a good argument to resist encryption. I hope that he chooses to embrace encryption, while recognizing that it is not applicable to every environment or computer. He can still make an informed argument against it in his case, provided he is correct in his assessment.

POLICY

alaederach, I believe the folks that posted advice about resolving this through the proper channels to get an exception to the policy is your best route. Dont start argumentatively. Explain your concerns and keep an open mind about them. Start with a member of the team that is deploying PGP and ask what the proper procedure is to get an exception to the policy. If there is a project manager assigned, that would be the person to start with. Project managers are usually more open to the needs of your area, and have the power to address issues that are raised during the implementation process. Kindly explain your concern, and ask if a high performance system can be benchmarked and tested prior to the roll out of PGP.

PERFORMANCE

As a proud tin foil hat wearing network administrator whom has rolled out PGP, I did not find a performance hit that was enough justification to make an exception in our environment. However, the identified risk of data loss and theft was a concern for the traveling laptops. The servers were less of a risk due to the physical security controls that were in place. PGP was only rolled out to laptops in my environment. I would recommend extensive testing prior to the roll out for high performance machines. Boot times were slower, but were measured in seconds vs minutes. In every case where performance was an issue, it was typical problems that one might find on a windows machine, and was unrelated to the encryption.

SECURITY

Every time I have worked as a member of a team deploying a security measure, the same argument is claimed by someone. "There is no reason to do X as it can be subverted." That goes for policy, physical access controls, software, and hardware. Encryption is no exception to this. Yes, warm and cold boot attacks are possible. Yes, highly motivated individuals, groups, and governments may have the ability to access your data. Security is best used with many layers. It can be highly effective at reducing risk, and keep higher percentages of the population from accessing or corrupting your data. alaederach, your best argument here is risk vs reward. This is where you kindly make your claim that risk is low due to the low impact of data loss in your environment. At the same time, if you have good physical security controls, you might want to include that in your argument. If the data that your work produces is valued higher by the decision makers than what you are sharing with us, then you may want request the performance testing and explain the risk of lower production due to performance. Geeks love performance testing, and if the highest risk is determined to be your computing performance, you just might find an exception to the policy.

MYTHS

A network adminstrator that gets hit by a bus, will cause your data to be lost. FALSE. The majority of organizations that have the funds to implement a project such as this, will also have determined off site storage of encryption keys as well as any othe data that would be backed up. Usually it is a different geographical location that utilizes high physical security controls. Yes there will be members of the staff that will have access. That is why there are Human Resource controls in place to vet the administrators. I.E. background checks.

An encrypted drive can not be accessed to retrieve data. FALSE. encrypted or unencrypted, proper data backup methods should be in place. With PGP specifically, I created a bartPE cd that allowed retrieval of data on a hard

Re:Risk vs Reward

[Agar]

Thanks for the very fair assessment, and measured response that answers not only the poster's questions but most of the issues raised by others.

One comment: Due to customer feedback like yours, we moved the info and tools for PE disks out of the password protected section of the Knowledge Base (i.e., requiring a paid support agreement) into the public area.

And yes, I work for PGP.

HIPAA sucks

[tompaulco]

HIPAA doesn't get into very many specifics at all about HOW to secure the data, and so every company seems to come up with their own ideas of what secure means. When your company is like mine, we deal with protected healthcare information from dozens of different companies, all of which have their own views, sometimes contradictory, of how to protect the data. Of course, our salespeople fall all over each other to agree to whatever way every client wants their data protected.
One of the things they agreed to do was to PGP encrypt every drive. This includes the servers that no one can possibly walk off with without breaking through several stages of physical security.
Most troubling of all is that we discovered that our primary peice of third party software that we use to deal with the Protected Healthcare Information, inexplicably will not install on a drive with whole drive encryption on it. The third party company has no idea why this would be. We have been using this software for over 5 years and there is not really another alternative in the market right now. So in order to protect the information as we have agreed to do, we will just have to stop processing it altogether.
Which frankly, is fine with me, because I am sick of dealing with protected healthcare information, because apparently some strangers information is so important that I have to reveal every tiny detail of my life to the company and all of their clients including credit check, background check, criminal check, fingerprints, urine test, etc., etc. Why is strangers' data protected while my information is openly shared with anybody with a passing interest in doing business with my company?

1999 article!

[matt me]

Brilliant. Refer to a craze for pgp disk encryption, then worry about problems suggest by an article from 1999 !!! (nine years ago) about some software for Windows 95.

There are a couple of things left unclear.

[krunk7]

The author was unclear on whether his non-patient data is residing on the same physical space as the patient data. It would appear to me that this is the case.

The main reason is that a small subset of our researchers work with patient information

.

I would assume "our researchers" means they share "our lab's resources". I'd put money on the IT policy stating "any storage device containing sensitive patient data must be . . . ".

If this is the case, the poster is completely out of line. If you would like a solution to your problem of whole disk encryption interfering with your non-patient sensitive research, here it is (and I'm sure your IT dept would agree):

• Physically segregate the patient data from the rest of your research and encrypt the file systems the patient data is located on.

.

Yes, it may be more troublesome to reallocate space. Yes, it may cost more due to lack of support for certain compression algorithms in the form of extra storage space needed. However, it is required by law that this data on your storage devices be secure. You never mention actually speaking to the IT department or what their response was. They may provide alternatives or be open to suggestion of alternatives that would minimally impact your other users. However, that they want to secure this patient information and are willing to take steps to do so is a very good thing.

And no matter what the solution is, it's guaranteed to negatively impact the researchers that deal with this data in some form or fashion. Whether it be in work flow/productivity or in operational costs. So brace yourself for that. These "hinderances" and headaches are part of the price for working with patient data. Every bit as much the hard disks, lab materials, and labor.

Certs don't impress me

[mrraven]

Just because you handle "certifications" doesn't mean you engage in best practices. In fact as an old school Linux/Unix nerd who remembers the command line days I often find there is an inverse relationship between qualifications on paper and competence. The best hackers in the old school sense of hacking as creative coding were not the people who went though cubicle drone tech certs., but those who had a passion for computers starting with a TRS-80 with a tape drive when they were 12. Most of these people later became bearded "hippies" with no certs whatsoever and those people now run entire networks at the world wide level despite never having had a cert. Ignore the advice of these people at your own peril.

Re:Certs don't impress me

[rob_benson]

I also know a lot of self-described "hackers" who don't know their ass from their eyebrows when working in a real IT environment. I find that a cross between enthusiasm, know-how, and certification works well.
With no certs or educational achievements you are hurting your career options. I mean honestly if you are that good, your career is worth spending a lousy couple hundred on a cert that will help you get a job.
Of course, I've seen some super-certified idiots as well too.

Re:Certs don't impress me

[yttrstein]

I'm not entirely sure that you understand what PCI DSS is or what it's related to, but a quick google search should do you well on that one.

By the way, my first computer was on a Commodore PET in 1978. My second was with VAX/VMS in 1979, and from then I never looked back. I'll admit right here and now that I do not currently, nor have I EVER held a "certificate" of any sort of computing or networking. My career pre-dates their necessity.

Re:Certs don't impress me

[1lus10n]

Well said sir !

Re:Certs don't impress me

[mrraven]

Thank you, thank you, I'll be here all week. :)

Security is a Three-Legged Stool

[CohibaVancouver]

According to Gartner, 70% of computer theft is internal, which means the encryption password may be known. It's further complicated by the fact that many users have the encryption password stuck on their machine on a post-it, or have their RSA SecurID token key in their (unlocked) desk drawer or in their computer bag.

You need to look at security as a three-legged stool. If any leg is missing, the stool falls down:

1) Physical security: Locks, security cables, security cages etc.
2) Encryption - Provides data protection
3) Theft recovery and secure data delete - Via a product like Computrace

With these three legs you'll be covered.

Also a crash recovery nightmare

[Anonymous Coward]

Encrypted partitions are excellent for their intended purpose: To safeguard the confidentiality of sensitive data. But an "across the board" policy of encrypting every HD in a whole shop is simply nuts. In addition to the performance problems with intensive computation requiring constant read/write, the way to recover from a file system corruption problem with an encrypted partition is very often "Kiss your data goodbye, it is gone forever, period." So, add the cost of a major upgrade in your offsite backup process, in money and network and in-the-box processing overhead, to whatever the PGP license costs /and/ the vastly increased risk of major data loss.

Re:My company did this and it sucks for performanc

[compro01]

In general, it seems that anything reliant on throughput doesn't really care about FDE. It will take up some CPU time, but the system is already so limited by the physical disk itself, the difference is minimal.

But if the workload is heavily based on lots of small transfers, the FDE en/decrypt adds quite a bit of latency and can cause very significant performance loss. If the drive takes 5ms to seek for data, then another 5ms* for the data to be decrypted, and you're doing this dozens of times per second, you're looking at a 50% performance cut, in addition to the CPU time used.

In general, pretty much everything most people use a computer for falls into the first category and they're not going to notice a difference, but in the latter case, the performance loss can be utterly deviating.

Obviously, the only way to figure out which case this guy falls into is to test.

*number being pulled out of the air, though I'm pretty sure this is a decent ballpark figure.

WDE only protects against a few things

[Todd Knarr]

Your IT people need to remember that whole-disk encryption only protects against some threats, not all. It's mainly going to protect against physical theft of the drives themselves, or the computer they're in. That means it's going to mainly benefit laptops that're out in the world where they can be easily stolen. Office desktops, if they're stolen that means someone had physical access to the building to take them. If the IT department can't name the last time a desktop was stolen from the building, theft is probably not an issue. Servers aren't likely to be stolen at all, they're locked up in a presumably secured data center and I just don't see an outsider being able to get in there let alone unrack a server and walk out with it under their arm. Again, if IT can't name the last time a server was stolen it's probably a non-issue.

And even in the case of a laptop, the encryption only protects the disk while the computer's powered off or in a state where the encryption software's discarded the key and won't decrypt the disk again without you re-entering the password. We found where I work that the standard suspend mode of the laptops does not trigger PGP to prompt for the password on resume, for instance. Since most of our people leave their laptop suspended while carrying it around rather than turning it completely off (to speed up start-up), the PGP encryption essentially isn't protecting the disk at all since the thief won't need the password to get the data decrypted. I don't count the normal screen lock, since if that were sufficient you'd just force password lock on the screen saver and not need encryption at all.

And of course whole-disk encryption won't protect you at all from viruses, trojans and other malware that gets onto the system and starts sending data back home. That stuff's running after you've helpfully given PGP the password and it's cheerfully decrypting data for you, and it's running as you so PGP thinks it's you accessing the data. Again, for office desktops and servers remote access by malware's probably a bigger concern than physical access to the machines and you need something other than whole-disk encryption to protect against those threats.

To be honest, I'm much more of a fan of removeable media. Put the patient data on a USB stick, then plug the stick in to access the data and remove it when you're done. If the sensitive data isn't on the computer then nobody can get it by stealing the computer. Just don't fall victim to those "encrypted" USB sticks, many of them either use algorithms that're trivial to break or they fail miserably at some point (eg. leaving the encryption key in unencrypted unprotected space where it can be extracted and used by a thief). It's much easier to lock some USB sticks or CD/DVDs up in a secure drawer than it is to protect a computer.

Re:My company did this and it sucks for performanc

[Agar]

Seriously, you have a problem either with the hardware configuration, other software, or the OS. Sometimes bad sectors on the HD during the encryption process will cause Windows to downgrade disk access to PIO mode, slowing things way down. Maybe there's some disk indexer running...could be something else.

I run PGP WDE every day, have since a beta of the first product, and what you're seeing is *not* normal. ...and yes, I work for PGP.

That was a case of improper setup

[Beryllium Sphere(tm)]

HIPAA has requirements for availability as well as confidentiality, so any place handling protected patient data should set up an ADK. An Additional Decryption Key is a PGP feature that allows reading an encrypted disk with a corporate recovery key.

BitLocker and (moving away from whole disk) EFS have their own ways of accomplishing the same thing.

Maybe a little late here, but...

[alexfeig]

I run the IT Department for a company in the EDU industry.

We have about 80 laptops in the field, and about 2x that in desktops.

Since we deal with a lot of sensitive data (read: personally identifiable) I have been deploying PGP WDE for the past few months to all laptops (no desktops).

Speed:
Our users primarily use a web browser and Outlook. No one has complained about speed yet. Caveat: While it's encrypting, the laptops will slow to a crawl until it's done. We've had a lot of complaints, even after my helpdesk guys advise them.

Administration:
Couldn't be easier. Someone mentioned that you could essentially "lose the key." Not possible, and I've tested it. WDE creates a backup 1 time use token so that if someone forgets their password you're not up a creek. Also, the server side software allows for backups, so you're covered on that end.

Cost/etc:
Expensive as hell, in my opinion, but a hell of a lot cheaper than having to pay our lawyers. My impression is a very positive one. The only thing that leaves much to be desired is support. You have to submit a ticket online, and if you're lucky, you'll get a call back within the day.

PGP experiences

[Anonymous Coward]

So my work did this to all desktops and laptops (though not servers, thank goodness). Of course the ironic bit is these desktops are all in a secured buidling...

This is on Windows boxes so YMMV but we've had lots of complaints. Stupid stuff like opening a new file explorer has a 2-3 second lag each time. Scrolling down a list of files in a directory has a 3-5 second lag.

The worst part though is when the mandatory "noon" virus scan starts. We actually had to move anyone who didn't already have a dual-core system to one so this wouldn't lock up their box for 10-15 minutes. And I do mean lock up.

All in all we've learned to live with it in the way folks learn to live with a persistent rash -- annoying but not life threatening.

Now, as many have said, in a HPC situation it might be different...

Re:Encryption is good for security, bad for perfor

[medelliadegray]

Hey Friend,

I hope your PC has a UPS, with auto-shutdown mechanisms in place in the event of power loss.

Otherwise your placing your Raid-5 data at risk due to the "write hole" issue associated with Raid5.

Raid1 / Raid10 or ZFS would be a safer alternative if your data has value.

Recovering encrypted disks

[BenEnglishAtHome]

Wow. When you say this:

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.

I have to feel for you. I'm really sorry that whatever solution you've implemented is this crude.

This sounds like you're talking about situations, even physical damage, where an unencrypted disk could be slaved to another machine and the data recovered. In those cases, where I work we slave the disk to a functioning machine and mount it with an encryption cert sent to us from the group that centrally manages our encryption. Then we copy the data (or, if it was just a software problem, fix what was wrong), build the user a new machine, put the data on the new machine, and the user walks away happy. They'll be without a computer for a day but, even though our security policies are absolutely ass-aholic about requiring full-disk encryption *everywhere*, we've been able to recover data in every case where we would have been able to recover it from unencrypted disks.

Why whole disk?

[sherriw]

Considering that much of your hard drive consists of non-private data, like the operating system, program install files, and spurious user junk, why bother encrypting the whole disk? Why does anyone bother? Just have an encrypted directory, partition, or even a second small hard drive and save all super-top-secret files in there.

Re:Encryption is good for security, bad for perfor

[ChrisA90278]

Sun, right now will tell you otherwise. They are pushing what is really just "software RAID" and are getting good cost performance. So I think what performance you get depends a LOT on what hardware and software you are using. If it is a generic PC running Linux I'd expect so-so midle of the road performance but if you bought both better hardware and better software you could get better performance out of software RAID. I've seen software RAID be able to "flood" two Gigabit ethernet ports. The advantages of software is that it is so much more flexible. Just compare Solaris' ZFS to anything else. You have to on the hardware side buy some very expensive products (like going with NetApp) if you need features like point in time snapshots and to be able to reconfigure on the fly and all the other stuff that ZFS gives you.

Re:Encryption is good for security, bad for perfor

[jlarocco]

Well I'm not suggesting people go buy a new multi-core machine just for a tiny TrueCrypt speedup, but since most new machines have multiple cores they might as well take advantage of it.

As for modifying the software, it probably depends on how much effort was required to get the speedup.

Protozoa demand privacy too!

[toby]

You insensitive clod...

New to me

[toby]

Never heard Microsoft called "stupido-quark" before, but if the cap fits...

Re:My company did this and it sucks for performanc

[mistahkurtz]

The real problem is after that. The minute Windows loads up the disk starts churning and barely ever stops.
It just churns and churns and that little hd light just keeps going and going.

swap file?

My!

[toby]

You *have* been away a long time then.

Start with reality of headless HPC farms

[Anonymous Coward]

Amazingly, everyone ignores the fact that an HPC cluster will have hundreds or thousands of headless nodes into which no boot-time passphrase can be entered.

Now, what is the value of FDE when the key is baked into the system for unattended boots? You need to protect the servers from physical theft. The only value of FDE would be marginal convenience in discarding used hard disks instead of destroying them. If someone can get into the machine room to steal the node and disk, they can also subvert the local disk-based or LAN-based boot processes and get the baked in passphrase.

It makes little men feel big.

[toby]

...just like a gun does, I guess.

Damn, now I have to change my XOR key

[toby]

You insensitive clod!

Re:Encryption is good for security, bad for perfor

[raddan]

Wow. A good indicator of whether someone doesn't have a CS education (or cheated their way through their CS education) is if they think that modern CPU speeds are at all a factor in whether to remove the need for fast disk subsystems. For applications where speed is the most important thing, programmers will attempt not to use the disk as much as possible. But when an application does use disk (and this is unavoidable in some circumstances-- e.g., file servers), your fast CPU does not change the fact that your CPU is many, many orders of magnitude slower than your physical disk.

Let's take a typical 2GHz CPU. This machine's clock ticks 2E9 times per second. If this machine has all of its ducks in a row, it can add a handful of numbers in a single clock tick. This is extremely fast, and here's HOW fast: For the sake of argument, let's say that you can perform, on average, 1 operation every 10 ticks on this machine, and so, 1 operation takes 5E-9 seconds.

Now, your typical access time on a fast hard disk—the time needed simply to locate the data, since this is the slowest part— is about 4 ms, or 4E-3 seconds. This is 6 orders of magnitude difference from a hard disk.

Put it this way: if we were to scale the above process so that 1 operation happened in one second, your computer would have to wait a little more than 9 days for the disk just to access the data, let alone read it. S-l-o-w.

Unnoticeable on my Macbook Pro

[Anonymous Coward]

I've been running PGP whole disk on my Mac for several months and the overhead is unnoticeable, so much so that I forget it's there until it's time to reboot and I'm presented with the passphrase prompt.

Re:Encryption is good for security, bad for perfor

[Actually, I do RTFA]

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

That's because the biggest costs from Truecrypt come in random access, not reading linear data. And USB disks don't have the random access issue.

Re:Encryption is good for security, bad for perfor

[afidel]

Yeah, the DoD machines ARE on the Internet, how do you think researchers from around the country get access to them to perform experiments? Now, classified work has to be done from a secured terminal either onsite or at a connected millnet site, but the unclassified interface IS available for many DoD computers from the Internet(2).

Busy Busy Busy

[Nom du Keyboard]

For example, dynamically reallocating a partition on a PGP encrypted disk is apparently not possible.

Yeah, like I do that every day.

This protest sounds a lot like a Straw Man fallacy.

Related Question

[mike.mystyleit]

Hey, I can't help you with your question as I know very little about encryption myself. But I do have my own question. Recently my boss (who works off a laptop) has asked me about encrypting a single partition on his XP laptop. He doesn't want to encrypt everything out of fear of the performace hit. Can anybody recommend a good solution for single partition encryption? Thanks, Mike

Re:Related Question

[JSBiff]

Well, PGP might have a solution, or, I have been using TrueCrypt for a while and have been pleased with it. TrueCrypt is licensed with an Open Source license (it's not GPL, but is open source), and is also free-as-in-beer.

RAM is cheap!

[Mandatory Default]

The solution to this is obvious. If PGP encryption is required on all drives, fine. Just order 500GB of RAM and only use the drive for backup. That's only about US$6000 at today's prices. Cheap ;-)

Referenced article is way out of date!

[overThruster]

The Network Computing article referenced here is ancient history. It says that PGP was "recently acquired by Network Associates" and it talks about support for FAT16 and FAT32. Network Associates sold PGP way back in 2002. See: PGP Corporation History

I recommend the original poster get some current information on the PGP product.

WDE: Never even noticed it was there...

[Anonymous Coward]

Anyone who is looking at the performance hit will find it, but I've never noticed on on my very low-end p4 Celeron laptop.

Most people overestimate what they really spend their time waiting for. Longer boot times? I reboot once week, never notice, etc. This is a typical narrow view. Try doing something you've always done and compare the times. Then check the time you waste reading Slashdot every day.

What is the value of not losing your client's data? Priceless.

Re:Encryption is good for security, bad for perfor

[CodeBuster]

It sounds like you had a bad experience with a "leaky" implementation of disk encryption and by "leaky" I mean that it was not virtual hard disk (i.e. lowest possible level encryption). Incidentally, this is also why I object to the Windows Vista "bit locker" encryption scheme, it does not implement the pre-boot virtual disk method. The best way to implement full disk encryption is to employ the pre-boot virtual disk method used by TrueCrypt (and also PGP, but I have no personal experience with that). That way, for all intents and purposes, the OS is completely naïve about the encryption (i.e. it is transparent to the OS) and therefore no special handling, other than the special disk driver for the virtual encrypted disk, is required on the part of the OS. It would be like using a special non-standard hardware for your data, the OS just asks you for the driver that works with that hardware (virtual disk in the case of TrueCrypt since the disk is actually the underlying HDD, possibly even hardware RAID if you have another layer below that). This is the "best" implementation IMHO, because it is completely transparent to all existing software, including the OS, and uses the existing facilities to seamlessly insert encryption into the hard disk read/write chain.

No security breach? Really?

[Anonymous Coward]

Your website's down...

Re:No security breach? Really?

[Anonymous Coward]

nah, he just encrypted the dns

Solves nothing

[bluefoxlucid]

Don't do high performance work on laptops. For servers etc, whole-disk encryption does nothing; insiders can break it by hardware key-logger or just logging in and taking the data on a personal drive, while outsiders have to physically penetrate (read: Rush the guards!) and steal the hardware. As long as the system is on, whole-disk encryption does nothing (except waste CPU); if the system is in a physically secure building, you should focus on the physical security of that building. Degauss drives before sending them out!

Re:Encryption is good for security, bad for perfor

[cheater512]

Yes it does have a UPS, and the important data is mostly read and not written.

Answering a few of the questions

[joncallas]

Alaederach, I'm Jon Callas, CTO at PGP Corporation. I want to address a few of the issues you brought up.

First, the article that you link to is not about the current products.

The article is about "PGP Disk" which is now what we call "PGP Virtual Disk." That is a container-disk encryption system. It is still offered along with PGP WDE, as it's nice to have both. There have been many improvements to it since that article was written.

My guess is that article is over ten years old. There's no date on it, but based upon what he says -- he installed it on Windows 95 running an AMD K6 200-MHz computer with 9 GB of Ultra DMA EIDE drives and 64 MB of SDRAM memory -- my guess is that it dates from late 1997.

If you want to do a fair comparison, let's also test against the experimental Linux 1.2 kernel, too, which also dates from about that time. That article also talks about CAST (which is still an option in Virtual Disk, but WDE uses AES). I can go on, but you're not asking about that, you're asking about WDE. My point is that if you research our present products and reference an article about a different product from last century, it's not going to tell you what you want.

I want to talk about the three main issues I see here: partitioning, compression, and performance.

When it comes to partitioning, PGP WDE operates below the partitions. We think that this is a huge benefit. We do not presently support dynamic repartitioning. It's a goal, as our long-term plan is to support Windows, Mac OS X, and Linux on the same disk with multiple partitions. We're not there yet. My personal opinion is that partitioning made sense when disks had megabytes. It doesn't make sense when they have terabytes, except for some obvious exceptions, like that you want to have a triple-boot disk. Your situation seems to be different, and I'd love to hear your views and needs for dynamic partitioning.

There are no issues with compression with WDE or Virtual Disk. I don't even understand what the issue could be. An encrypting driver writes blocks of ones and zeros. It's below the file system as well as below the partitioning system. It all just works. I'm using WDE on all my computers, and it just works.

The last issue, which you didn't bring up, but is important, is performance. When you measure *any* WDE system, not just ours, there is obviously a performance loss -- because you're adding the encryption. This is even true with hardware encryption.

Nearly any number between "essentially zero" and 100% are true, given what you measure. On a steady-state running system doing normal tasks, the WDE overhead is essentially zero. Users won't notice it at all.

At the other end of the scale, we've done some performance measurement, and compared the real WDE driver against one that no-oped the encryption. The result is that the encryption takes about 1/2 the time of the total driver throughput. You can call this 50% or 100% depending on how you like to count.

In a real-world situation, the real factor is how much time you are spending in the disk driver. If you have a heavily IO-bound system that's spending 30% of its time in the driver, then WDE is costing you 15% of your CPU. But if you're compute-bound, then WDE is costing you literally nothing.

However, if you get a hardware encrypting disk, you don't improve the situation. We've benchmarked some of the new encrypting spindles against their non-encrypting versions. The performance overhead is much worse for those than for our WDE. It adds zero to your CPU, but it's a huge latency issue, up to nearly a one-quarter drop. This shouldn't be a surprise -- we're doing the encryption on a 64-bit Intel or AMD processor, and they're doing it on an embedded CPU on the controller. Which one do you think is going to be faster?

There are a set of advantages and disadvantages to doing encryption on the CPU or on the disk, but speed goes to doing it in software. The speed advantage of software is only to shift even more to t

How it works in business

[techno-vampire]

In business, those who can, do.
Those who can't do, go into management.
Those with no management skills go into marketing.

FWIW...

[SiriusStarr]

FWIW, I run LUKS FDE on my 2.2 GHz Dual-Core Thinkpad T61 (7200 RPM SATA HDD) and there is certainly no noticeable difference between with and without. My guess is that on any modern (read, multi-core) system, FDE is not going to make any major difference. It's not like it's some computationally-intensive public-key scheme.

PGP Recovery

[madhopsman]

I have successfully created a bootable PE cd that can mount PGP Partitions/Drives. This allows for recovery WITHOUT decrypting. A bad block on an encrypted drive is no different. If NTFS becomes corrupted or, heaven forbid, the master file table takes a dump, normally you WOULD have to decrypt first to fix, but not so with a bootable PE cd that can mount the partition. It is business as usual. There is MOST DEFINITIVELY a performance hit when running PGP, but mainly on the CPU. Disk performance itself is not very noticiable (i.e. somewhere between around a -7% in my own experience), but when there is high I/O, whach your system process take off. The filter driver for PGP runs under this process, and there is no doubt about it.

Re:feel-good actions

[yoderm]

in these type of departments all the computer are on all the time anyways

Completely agreed - the only threat that full-disk encryption really prevents against is someone actually walking out of the data center with the disk. Nice and all, but not a full solution.

The company I work for (www.vormetric.com) has a policy-based file encryption product, so you can say things like "under this directory only user foo can read and write to files, and use this particular encryption key". So other users can't get there, and even if they could it's encrypted. There's no performance hit for everyone else, and it's transparent to applications. You might want to check it out.

-Mike

The human issue

[Anonymous Coward]

I don't think the issue is with security of the system more then security of the files. People just don't think security when they use their computer. Of course the confedential files could just be encrypted, Truecrypt offers making encryption compartments where the data could be stored. Its just that most people wouldn't use it. By encrypting the whole system the IT guy, who will lose his job over a security breach, can confidently say that yes the data is protected 100% of the time.

Who is going to manage the keys. . .

[lisnter]

for all these encrypted machines? The OP doesn't indicate if the IT department is going to centrally manage them or if it's up to the individual workstation user. If the former, how are they going to distribute the keys and who's to say that the IT department secure enough to *not* be a single point of failure. If it's up to individuals how much do you want to bet that 50% of the passwords will be the name of your institution, your institution backwards or some other weak key. Unless the IT folks enforce a long and difficult-to-remember password strength model that's what you'll get. And if they do mandate long passwords then you'll get them sticky-noted to the monitor. Encryption is a good thing but just installing it doesn't really solve anything. I'm sure others have pointed this out above. . .

retirement of servers and disks

[Anonymous Coward]

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.

Until they're retired and disposed off.

Of course it's not like break-ins don't occur (regardless of locks).

Re:Encryption is good for security, bad for perfor

[Anonymous Coward]

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.

Thanks to Moore's Law the available CPUs are twice as fast.

Also, since we have systems that tend to have multiple cores now, RAID can be done one and "real" work can be done on another.

Mod parent up

[jonaskoelker]

+5 I Wish I Had That Idea ;)

I'm optimistic, slightly cautiously.

Re:Encryption is good for security, bad for perfor

[jonaskoelker]

Whole disk encryption is excellent for security, but it will bog you down in disk access times.

Really? For each sequential read, I'd think that you'd have a delay as the first block is decrypted, then everything is following sequentially with no extra delay and a constant amount of CPU usage.

Most desk-/laptop are vastly overpowered for the common applications (slashtube, textproc and media). In the few cases where maximum performance is needed (e.g. games), you typically move all data into memory, then do compute-heavy stuff with _very_ little I/O, then write back what you need to. If the I/O and computation are disjoint, there's no slowdown, only a delay.

Re:1%?! why is ssh so slow then?

[lpq]

1%? Is PGP that efficient? With standard SSH encryption protocols on a 1GHz P-III, I see 100% CPU usage
by SSH on the receiving end. It is considerably faster to use a FS protocol like CIFS to xfer files, than
attempt to stream files through encryption. Those are just slowdowns on Gigabit network traffic.

I'd think the hit on encryption would be alot more noticeable versus local disk traffic, though I admit to not having tried it -- I felt if encryption cut network throughput by 50% or more, it had to really hurt disk encryption.

So what's the difference between ssh vs. pgp protocols -- is it possible to apply a pgp type protocol to an SSH stream resulting in something like 1% network slowdowns? I guess I don't understand why network traffic would be so much more considerably compute intensive to encrypt vs. disk I/O....??

Can anyone shed some light on this?

IT is not there to serve you--you are there to

[mkcmkc]

serve IT. The sooner you absorb this modern truth, the sooner you will cease your futile struggle.

In all likelihood, your only practical alternative is to look for a new institute.

Re:My company did this and it sucks for performanc

[Growlor]

What you say may be correct, but he said the performance hit starts as soon as Windows loads. If this is literally true, then he probably doesn't have any apps running yet which makes me suspect a problem in the implementation. This is not typical to what I (or other people I have spoken to) have seen with mainstream encryption products.

Re: sig

[3p1ph4ny]

LSD was invented by a Swiss chemist named Albert Hofmann.

Little fish in a big pond

[mcohrs]

It is hard to argue against a user who is negatively impacted by company wide rules, especially when they will not be involved in any potential exposure to security issues. But the top guys see it a different way, they know the cost of a breach, whether it is ss#s, health information or other supposedly private data. These costs can be huge in money, reputation and even their jobs. I was often the rogue user, so I think I understand. I am also the IT guy in our small branch of a major medical university and I know how it sucks to have rules limit your ability to do a job with the limited available resources. On the other hand, I have been lucky, our IT organization is very big, but also very good and they try to accommodate user needs, but the university needs still come first. We are also in the process of securing every portable device with encryption software, I am a bit apprehensive myself. And so it goes

No problem

[lucm]

On workstations and laptops there is certainly no noticeable difference if you have a good FDE software (and *recent* PGP software is quite good).

Even on servers I would not worry. I remember a customer having FDE on a very busy database server and it was fine.

FDE is your friend, and can even save you some jail time: http://en.wikipedia.org/wiki/United_States_v._Boucher

Hmm.. why?

[JohnLeB]

Well, your not using public private keypair encryption except for some key managment.. the actual encryption is going to be by a symmetric algorithm. Now, it's going to load the cpu.. the trick is to get a fast algorithm, so use AES-256 for your symmetric. That's a lot faster than triple des or blowfish. Second.. why pgp?? oh, well, it's "known". If you can do it, create a silicon drive for yourself and use that for your code, although I'd be more worried about the windows swap file than my data access, given what a pig windows is anyway. Sux man to have to deal with that.. maybe you can dig some stuff out of bruce schneider's work and talk them out of "crypo-snake oil"

but what about the data in motion

[Anonymous Coward]

PGP or truecrypt does solve the problem of protecting data at rest granted there is a degradation in processing power. The issue stays that if you are moving the data around or forgot to lock your PC when you went for that smoke break ... your system is as vulnerable as there is no encryption. Over and over again we all read that majority of the data theft happens internally by employees. For this specific use-case how does PGP or truecrypt helps that researcher when he is about to submit the patent information to the authorities (data in motion).

If you look at an alternative view of data protection at a file-level the advantage you get over whole disk encryption is two-fold. Data at rest is encrypted and because the encryption is applied at the data itself, the data stays encrypted even in motion.

Because we live in a heterogeneous computing platform environment and not knowing the landing platform of the data a solution which is biased on the platform and carries encryption with it at all the time would be very much beneficial for business processes.

I am not saying whole disk encryption is a bad protection platform but it is a not a complete data protection platform. IMHO it leaves the data at risk of exposure. Complimenting the whole disk encryption strategy becomes very critical when compliance is in play for organizations and peace of mind for data owners.

We solved this issue with following the file level security philosophy and enforcing IT policies of how the data is encrypted. Also not knowing the platform of the data recipient poses another challenge. Looking out for a ubiquitous solution that will solve all our business problem, we came across a ZIP container approach. Talking to the inventors of the ZIP container all of our issues were solved in the most efficient manner. Just a first hand experience to share with the community.

All True, But

[DynaSoar]

The technical details raised in response are all correct, and they or other solutions existed at the time. The existence of technical capabilities do not influence the probabilities of humans to use them. When it comes to security, in the absence of strict guidelines such as HIPAA (which is relevant to patients but irrelevant to biomedical but non-patient data) people often choose to err on the side of more security.

Test it yourself - there is no disk speed impact!!

[Anonymous Coward]

It's always a case of 'your milage may vary', but putting Truecrypt on my laptop ***INCREASED*** disk speed by 10% (GRC.com confirmed this too).

However CPU impact, while copying a large file (90 second copy time), was up by 40%.

CPUs are faster than disks. If you have 40% spare CPU when you are reading/writing disks, there is no impact from using TrueCrypt.

I wish people would test rather than speculate.

Dom

Protozoa are people too...

[Anonymous Coward]

Protozoa are people too, and they deserve their privacy. If only one or two protozoa use encryption, that will cause fingers to be pointed, and so on. It's best if they all use it.

Not a big fan of Whole Disk Encryption

[Anonymous Coward]

I personally don't like whole disk encryption at all. Without even mentioning the Cold Boot Attacks, there are many reasons why I much prefer File Based Encryption. Read here for more info:

Full-vs-File-Based-Encryption/