Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!



Resisting the PGP Whole Disk Encryption Craze

smoon delay tactics... (480 comments)

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.

more than 6 years ago


smoon hasn't submitted any stories.


smoon has no journal entries.

Slashdot Login

Need an Account?

Forgot your password?