2

I wish to use a 2010 vintage quad core Xeon server to periodically encrypt 500GB eSATA drives. I have three questions:

1) I assume the current version of WDE is fully multi-threaded and throughput scales roughly linearly with the number of cores?

2) Am I able to restrict the number of cores utilised by the WDE process so as not to impact other work on the server?

3) Roughly how long should I expect each encryption to take?

There seems to be conflicting information around on the threading of WDE, even on the PGP KB site where I also asked this question (it is nearly dead there though) as a lot of older answers indicate that it is not offered.

3
  • Why do you have to encrypt everything? Does it really help to encrypt public data? Think about what you need to encrypt and why? Even if you have the cores to support fast encryption, decryption / encryption uses watt's of power! Also recovering from disk corruption is a LOT easier when the drive is unencrypted ,rather than a string of meaningless numbers. Nov 11, 2010 at 10:36
  • 1
    Personal data is being sent off-site, our regulatory obligations pretty much require full disk encryption for any data off the network. As you can therefore imagine this isn't something we do often, but in this case it seems unavoidable. Power usage is irrelevant, as is recovery as we can simply load up another drive if the drive is somehow corrupted.
    – Lunatik
    Nov 11, 2010 at 11:19
  • Not to put you off your desired solution, but why WDE? If you are using a *nix, there are a lot more simple and OOTB solutions available.
    – d-_-b
    Nov 17, 2010 at 8:30

3 Answers 3

2
+25

Assuming your eSATA drives can deliver close to standard SATA speeds and you are using 7200 RPM drives we're looking at sustaining around 80-100MB/sec across the whole drive under ideal conditions.

I don't have any specifics about PGP but benchmarks of AES encryption speeds in the range of 100-150MByte / sec per core for 2008 era CPU's (3Ghz Core Duo) are pretty easy to find [ e.g. this slashdot comment indicating 600-700Mhz of a 2.13 Ghz Pentium M to handle 30Meg/sec ] and I've seen similar rates for much older CPU's so I'm taking that as a baseline. Given that you are running on substantially better CPUs than those I have no doubt that a single core on your server will easily handle the maximum throughput of a single eSATA drive.

PGP WDE is block based which should help throughput reach those rates for a conversion but whether that is actually true depends entirely on how they implement it and I've no idea whether they have done it well. In any case the best result you could get would be a full read of the drive at an average of 100Meg/sec (sequentially reading block by block) and then a full write of the drive (sequentially writing block by block). For a 500GB drive that would be 1,000 seconds or about 17 minutes. That wont saturate a single core on your server, even allowing for CPU overhead for the drive IO.

The balance of probability is that PGP WDE's conversion algorithm does not handle IO as efficiently as I assumed above so the time taken to encrypt the drive will be substantially longer - you will need to test it to be certain but I wouldn't be surprised if it was an order of magnitude slower and the CPU overhead for the encryption tasks will be proportionately lower too.

One final note if you are using a Westmere class CPU (Xeon 56xx) then PGP WDE supports the new AES-NI instructions that should deliver a better than 50% real world performance boost - see this Toms Hardware article where they show the benefits for Bitlocker but the PGP WDE benefit should be at least as good.

Edited to add:
I feel that I wasn't really clear in the above - multi-threading isn't going to help you as far as converting a single drive is concerned. It might help a little if you plan to run multiple drives in parallel but unless you have hardware that can handle many drives concurrently the IO limitations of the drives will be a significantly larger bottleneck than CPU utilization. The anecdotal evidence on the web [ here and here for example ] about the conversion speed ranges from 25 to 50GB per hour - I'd expect a decent eSATA drive to be faster than those examples but it seems unlikely that it would be much better than 100GB an hour.

Finally there is a very good discussion on the cpu overhead of disk encryption in general in the comments on this PGP Blog post that reinforces the point that the CPU is not the main bottleneck, Read\Write latencies are the main problem.

1
  • Thanks for the extended explanation. In the end we went down a different route, but this is good info for future use.
    – Lunatik
    Nov 24, 2010 at 15:25
1

A few obvious searches on Google didn't turn up any hard answers to your questions about this specific product, so here's an estimate:

1) No idea if PGP is multithreaded but if it is, you should expect 50-80% increase in processing per extra core/CPU. 4 cores only give you 400% performance for some very, very specific workloads - and waiting around on data from disk that needs to be written back isn't one of them.

2) Task Manager lets you set CPU priorities on running processes, so that's at least one option.

3) I strongly suspect there will be very little overhead. Any recent Xeon CPU can do encryption faster than some random mechanical disks can write over USB 2.0. Which CPU is it, exactly? You can see here which ones have hardware support for encryption (AES-NI):

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

0

If you are in a position to change tools, have a look at Truecrypt

1) Truecrypt is highly parallelized and scales about linearly

2) You can specify the number of cores to use

3) As to speed, it will depend on how you connect the drive, the number of cores you can spare, the encryption algorithms used etc. Given the hardware you have, disk io will likely be the bottleneck, even with a sata connection. But download it and run the benchmark, or encrypt a drive and see for yourself. (There's a portable mode, so you needn't even install it).

3
  • Thanks, corporately tied into PGP though :)
    – Lunatik
    Nov 16, 2010 at 18:35
  • Beware of the TrueCrypt license. See: lists.freedesktop.org/archives/distributions/2008-October/…
    – mattdm
    Nov 16, 2010 at 20:36
  • The warning about the TrueCrypt license concerns version 2.5 of the license. TrueCrypt is now distributing their software subject to version 3.0 of their license document.
    – gbroiles
    Nov 21, 2010 at 5:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .