Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Resisting the PGP Whole Disk Encryption Craze

samzenpus posted about 6 years ago | from the what-do-you-think dept.

Encryption 480

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

Sorry! There are no comments related to the filter you selected.

Overhead (5, Interesting)

Anonymous Coward | about 6 years ago | (#25566447)

Truecrypt Whole Disk Encryption has less than 1% over head. I can't see the problem. Surely the patent and IP information security outweighs this minimal overhead.

Repeat after me (4, Interesting)

MosesJones (55544) | about 6 years ago | (#25566657)

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

People misunderstanding the question... (5, Insightful)

wanax (46819) | about 6 years ago | (#25566883)

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:Overhead (5, Interesting)

stranger_to_himself (1132241) | about 6 years ago | (#25566885)

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 (1)

emj (15659) | about 6 years ago | (#25567101)

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

Encryption is good for security, bad for performan (4, Insightful)

WK2 (1072560) | about 6 years ago | (#25566449)

Whole disk encryption is excellent for security, but it will bog you down in disk access times. Depends on a lot of things, but reading and writing files can slow down up to 50%, but usually the slow-down is much less. If you are doing something that involves a lot of disk access and it doesn't need to be encrypted, then create a special, non encrypted partition for that.

Re:Encryption is good for security, bad for perfor (2, Interesting)

QuantumG (50515) | about 6 years ago | (#25566491)

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.

Re:Encryption is good for security, bad for perfor (1, Funny)

msormune (808119) | about 6 years ago | (#25566521)

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

Re:Encryption is good for security, bad for perfor (4, Insightful)

cheater512 (783349) | about 6 years ago | (#25566765)

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.

Re:Encryption is good for security, bad for perfor (5, Insightful)

discord5 (798235) | about 6 years ago | (#25566931)

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.

Re:Encryption is good for security, bad for perfor (1)

amorsen (7485) | about 6 years ago | (#25567085)

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 (4, Informative)

imsabbel (611519) | about 6 years ago | (#25566597)

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.

Re:Encryption is good for security, bad for perfor (3, Interesting)

GoulDuck (626950) | about 6 years ago | (#25566661)

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 (4, Informative)

IWannaBeAnAC (653701) | about 6 years ago | (#25566713)

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!

Re:Encryption is good for security, bad for perfor (1)

borizz (1023175) | about 6 years ago | (#25566759)

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 (1)

calmofthestorm (1344385) | about 6 years ago | (#25566797)

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!

Re:Encryption is good for security, bad for perfor (4, Interesting)

KStrike155 (1242390) | about 6 years ago | (#25566877)

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!

Re:Encryption is good for security, bad for perfor (2, Interesting)

IWannaBeAnAC (653701) | about 6 years ago | (#25566979)

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 (1)

WK2 (1072560) | about 6 years ago | (#25566921)

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 (4, Informative)

calmofthestorm (1344385) | about 6 years ago | (#25566665)

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.

Re:Encryption is good for security, bad for perfor (4, Insightful)

nmg196 (184961) | about 6 years ago | (#25566733)

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 (3, Informative)

xouumalperxe (815707) | about 6 years ago | (#25566773)

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 (3, Informative)

calmofthestorm (1344385) | about 6 years ago | (#25566775)

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.

Re:Encryption is good for security, bad for perfor (2, Interesting)

bhima (46039) | about 6 years ago | (#25566747)

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 (2)

calmofthestorm (1344385) | about 6 years ago | (#25566793)

"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 (1)

somersault (912633) | about 6 years ago | (#25567023)

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 (4, Interesting)

calmofthestorm (1344385) | about 6 years ago | (#25567113)

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:Encryption is good for security, bad for perfor (3, Interesting)

TGoddard (1058678) | about 6 years ago | (#25566981)

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.

PGP expanding virtual disks? (2, Interesting)

mlts (1038732) | about 6 years ago | (#25566453)

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 (4, Insightful) (1392595) | about 6 years ago | (#25566457)

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 (4, Informative)

Smertrios (550184) | about 6 years ago | (#25567045)

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.

Burning question is... (-1, Offtopic)

Mike_Entropian (1379935) | about 6 years ago | (#25566459) Tetrahymenas really have four Hymens [] .

Isolate sensitive data (2, Interesting)

sugarmotor (621907) | about 6 years ago | (#25566465)

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.


Re:Isolate sensitive data (5, Informative)

Anonymous Coward | about 6 years ago | (#25566559)

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 (4, Informative)

postbigbang (761081) | about 6 years ago | (#25566681)

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 (5, Insightful)

jonaskoelker (922170) | about 6 years ago | (#25566595)

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 (3, Insightful)

calmofthestorm (1344385) | about 6 years ago | (#25566671)

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

Re:Isolate sensitive data (2, Informative)

Anonymous Coward | about 6 years ago | (#25566811)

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 (1)

pythonhacker (898864) | about 6 years ago | (#25566965)

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.

Policy Exception (3, Insightful)

Anonymous Coward | about 6 years ago | (#25566467)

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 (4, Insightful)

jamesh (87723) | about 6 years ago | (#25566739)

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 (1)

Peter (Professor) Fo (956906) | about 6 years ago | (#25566779)

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.

Disk&CPU (2, Interesting)

MortenMW (968289) | about 6 years ago | (#25566499)

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

Here's a quick experiment (5, Informative)

jonaskoelker (922170) | about 6 years ago | (#25566509)

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 (3, Insightful)

LiSrt (742904) | about 6 years ago | (#25566703)

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

From experience (2, Insightful)

Anonymous Coward | about 6 years ago | (#25566515)

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 (0)

Anonymous Coward | about 6 years ago | (#25566583)

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 (0)

Anonymous Coward | about 6 years ago | (#25566643)

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 (0)

Anonymous Coward | about 6 years ago | (#25566751)

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 (2, Insightful)

Alpha Whisky (1264174) | about 6 years ago | (#25566689)

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 (1, Informative)

Anonymous Coward | about 6 years ago | (#25566867)

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 (0)

Anonymous Coward | about 6 years ago | (#25566983)

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 (1)

Solra Bizna (716281) | about 6 years ago | (#25567091)

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.


Re:From experience (1)

RMH101 (636144) | about 6 years ago | (#25566973)

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.

Problems (0)

jcookeman (843136) | about 6 years ago | (#25566523)

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 (3, Insightful)

scientus (1357317) | about 6 years ago | (#25566547)

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! (0, Offtopic)

Ceriel Nosforit (682174) | about 6 years ago | (#25566549)

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 (1)

Errtu76 (776778) | about 6 years ago | (#25566551)

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 (1)

Jellybob (597204) | about 6 years ago | (#25567003)

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.

Incompatible? (3, Interesting)

Bromskloss (750445) | about 6 years ago | (#25566563)

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? (2, Informative)

calmofthestorm (1344385) | about 6 years ago | (#25566853)

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

Compression? (1)

91degrees (207121) | about 6 years ago | (#25566581)

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

What are you trying to prevent? (2, Insightful)

Nicolas MONNET (4727) | about 6 years ago | (#25566615)

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.

apply security if you really need it! (5, Informative)

ekran (79740) | about 6 years ago | (#25566617)

- added security

- 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! (1)

Bert64 (520050) | about 6 years ago | (#25566857)

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

Disk Encryption (2, Interesting)

mseeger (40923) | about 6 years ago | (#25566629)


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 (1)

Saunalainen (627977) | about 6 years ago | (#25566817)

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


Communicate. (1)

elh_inny (557966) | about 6 years ago | (#25566641)

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? (2, Informative)

Anonymous Coward | about 6 years ago | (#25566645)

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 (1)

omb (759389) | about 6 years ago | (#25566655)

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

Truecrypt does that and is better (4, Informative)

CuteSteveJobs (1343851) | about 6 years ago | (#25566659)

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

Re:Truecrypt does that and is better (2, Informative)

mokeyboy (585139) | about 6 years ago | (#25566833)

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 (1)

ConallB (876297) | about 6 years ago | (#25566997)

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

Put things into perspective (2, Informative)

Anonymous Coward | about 6 years ago | (#25566683)

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.

Suck it and see (1, Flamebait)

RationalRoot (746945) | about 6 years ago | (#25566687)

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 (3, Insightful)

DynaSoar (714234) | about 6 years ago | (#25566695)

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.

I've another fear (1, Insightful)

kanweg (771128) | about 6 years ago | (#25566699)

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


5 reasons (3, Interesting)

Knightman (142928) | about 6 years ago | (#25566705)

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.

Drive Errors? (5, Insightful)

CopaceticOpus (965603) | about 6 years ago | (#25566709)

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.

It's impossible to compress encrypted data (0)

kaltkalt (620110) | about 6 years ago | (#25566725)

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 (1)

Duckie01 (10586) | about 6 years ago | (#25566841)

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 (0)

Anonymous Coward | about 6 years ago | (#25566869)

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

Re:It's impossible to compress encrypted data (1)

kaltkalt (620110) | about 6 years ago | (#25567027)

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 (-1)

Anonymous Coward | about 6 years ago | (#25567037)

If properly encrypted, the resultant cyphertext should be completely random - any patterns mean it is pseudorandom and thus not properly encrypted

Urm, no. Encrypted data is not random - otherwise it would be useless. And it almost always can be compressed, just not easily.

In fact you gave an example - a PGP encrypted file (say with a 1024 bit key) containing nothing but 10,000 "W"s can be compressed from 10,000 bytes to 129 bytes - 128 for the key, and one for the letter "W". All 10,000 bytes of the encrypted file can be reconstructed from those 129 bytes. That's a compression ration of 77:1.

From me going to a fully encrypted machine... (1)

Kjella (173770) | about 6 years ago | (#25566769)

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.

Random Experiences with disk encryption (5, Informative)

quietwalker (969769) | about 6 years ago | (#25566781)

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.

Don't resist! (0)

Anonymous Coward | about 6 years ago | (#25566789)

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.

Why are you writing to slashdot? (5, Insightful)

Idaho (12907) | about 6 years ago | (#25566805)

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? (1)

EmagGeek (574360) | about 6 years ago | (#25566947)

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? (2, Insightful)

TuaAmin13 (1359435) | about 6 years ago | (#25567109)

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.

Don't encrypt bulk, public data (1)

MichaelSmith (789609) | about 6 years ago | (#25566821)

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

Anonymous Coward | about 6 years ago | (#25566901)

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

Obligatory (1)

Whiteox (919863) | about 6 years ago | (#25566851)

I, for one, welcome our Tetrahymenian Overlords!

Think about the purpose of Full Disk Encryption (5, Insightful)

hAckz0r (989977) | about 6 years ago | (#25566859)

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.

Encryption Experiences (1)

ConallB (876297) | about 6 years ago | (#25566969)

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

To defy PGP encryption ... (1)

VincenzoRomano (881055) | about 6 years ago | (#25566985)

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 (2, Interesting)

ACK!! (10229) | about 6 years ago | (#25566991)

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!!?? (1)

ThePhilips (752041) | about 6 years ago | (#25567005)

[...] 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 (5, Interesting)

segedunum (883035) | about 6 years ago | (#25567013)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?