What impact does full hard drive encryption have on performance?

We have HP notebooks here at work, and it is policy to have HP's hard drive encryption turned on to protect client databases and IP in the case of loss/theft.

I was wondering if there was any evidence of a performance hit in this situation? The machines are primarily used as development workstations. Anecdotal evidence here suggests that the machines are slower.

Should we be using another approach (i.e. only encrypting the sensitive data as opposed to the entire disk)?

From serverfault csjohnst

• The only proof is to measure. Take timings on a laptop with no encryption and compare with one that does. Of course there will be overhead in the encryption, but don't rely on a subjective "feels slower". What encryption are you using? Bitlocker? 3rd party app?

  As to the final question, it is too easy to accidentally miss (or even define) what is sensitive data. So I would keep the whole disk encryption if possible.

  csjohnst : We're using the built in HP encryption - "Drive Encryption for HP Protect Tools"
  From 20th Century Boy

• The "HP Protect Tools" is a rebadged McAfee/Safeboot FDE product. The performance impact shouldn't be too bad -- I'm assuming that you're using AES.

  We encrypted about 5,000 laptops three years ago, and our folks didn't report any significant performance issues. A few older boxes blue-screened, that's about it. You may be experiencing slowdowns immediately after enabling encryption... encrypting the disk can take 8-20 hours depending on the vintage of the equipment and size of the disk.

  From duffbeer703

• To answer this question, we need to know: is your app disk bound, CPU bound, or something else? Traditionally disk encryption involves a minor hit to performance; disk is usually slow that the decryption overhead is miniscule. However, if CPU is a concern, this can get hairy.

  Development workstations are usually CPU powerful, to improve productivity. Faster build times, autocompletion/intellisense, automated unit tests, etc. Normally a laptop's compromises in the name of portability hinder the idea; giving developers a laptop suggests you've already run out of ideas for spare CPU cycles and might be able to afford disk encryption.

  What you need to do as an IT professional is build a model of what developers need computational power for, and benchmark how those tasks fare under proposed conditions: no encryption, full disk encryption, and partial encryption.

  From jldugger

• We've used Safeguard Easy for years and Truecrypt's whole disk encryption since it came out, and neither has caused a big performance hit; even the older notebooks run development and database software without a noticeable difference in speed. Some people will even tell you that whole disk encryption software makes some operations run considerably faster due to compression, improved drive read routines, pipelining and the like. I wouldn't go that far, but as with most things, the truth is probably somewhere in between.

  The peace of mind from encrypting your disk, particularly if you have any kind of regulatory/compliance threshold in your industry (or are just paranoid) is worth the minimal hit of the encryption software we've used for this purpose.

  Thomas Denton : I have been using truecrypt for about a year now and don't really even know it is there. I have also had my sales team tell me their machines are faster after we encyrpted them.
  From nedm

• My own experience is that ca 30% of the CPU will be dedicated to crypto, and a 50% hit in disk performance. I've tried several encryption alternatives - SafeGuard, OSX FileVault, PGP WholeDisk.. the same rule of thumb seems to apply. The CPU-use is particularly annoying though, as it affects battery time too.

  A quick google search revealed this test which seems to verify my gut-feeling: http://www.isyougeekedup.com/full-hard-disk-drive-encryption-benchmarks-and-performance/

  sleske : Note that the benchmark on isyougeekedup.com (which has a different address) is a synthetic benchmark. It's not clear how this relates to real usage.
  From Commander Keen

• For the love of God and all that is pure and right, stay away from Credant!!

  It is used in our (non-technology) company and virtually all the developers have a special security waiver to not have it installed on their PCs nor laptops. It suffers from horrible performance when accessing many files at once, like when compiling code. We also had an issue where we had a service that would read the registry and other configuration files, which started up before user login. Well, as the files were not unencrypted until after the user logged in, the service would die an early, horrible death.

  Also, once this steaming pile of code is installed, it is supposedly as hard to uninstall as IE, but this has not been verified in a non-lab environment because it has usually resulted in hosing the system requiring a reimage. YMMV

  From Ed Griebel

• Not sure if you can do this (maybe in a lab?) but can you try rerunning these tests with AV uninstalled (or at least disabled). The reason I suggest this is because we had a customer with a similar issue as yours (except they had more delay writing to the drive then deleting; they also had the write cache support issues that you have) and we reran our benchmark tests with AV removed from the system and found that Win2008 (before R2 was released) out preformed Win2003 by alot. Turned out that the AV was responsible and we had to find a different AV provider.) Not sure that it will help you or not but it's something to check if you have the option.

  From Phillip