Print

Welcome to Smokey's Security Forums.

Guests have only limited access to the board and it's features, please consider registering to gain full access!

Registration is free and it only takes a few moments to complete.

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[pepak]

I would expect nowadays, with single core processors gone, that especially these tasks would be performed in parallel. There is no need to stop reading from the disk until you have the previous sector decrypted (not even with only one core!). I imagine a queue for undecrypted sectors, and multiple threads (eg. number of cores) working on decrypting them.

I agree that it would be awesome. Unfortunately nobody has been able to achieve this ideal state yet.

They claim to have fixed. I have seen the same claim with BCVE and TrueCrypt.

The changelog of BCVE doesn't tell about any changes in that respect,

It was mentioned as one of the features of 2.xx line, I believe.

whereas the changelog of TrueCrypt (6.2) says: "The I/O pipeline now uses read-ahead buffering, which improves read performance especially on solid-state drives, typically by 30-50%".
To me, read-ahead buffering sounds exactly like "I read sectors ahead (of decrypting them/of waiting for previous sectors to be finished)".

Yes. That's what I mean I have read such claims. I have yet to experience the reality that would match those claims.

Sorry if I sound pessimistic.

[fender]

The data needs to be read from the drive, that's one delay. Then it needs to be decrypted, which is another delay. After that a new read can happen. I know encryption tools try to paralelize this (read more data while decrypting the previous batch), but their success seems to be very limited, if any.

"The data needs to be read from the drive" - This is not a "delay" in comparison, because this needs to happen regardless of encryption.
I would expect nowadays, with single core processors gone, that especially these tasks would be performed in parallel. There is no need to stop reading from the disk until you have the previous sector decrypted (not even with only one core!). I imagine a queue for undecrypted sectors, and multiple threads (eg. number of cores) working on decrypting them.
Yes, I am using a dual core (P8600, see my first post for specs).

They claim to have fixed. I have seen the same claim with BCVE and TrueCrypt.

The changelog of BCVE doesn't tell about any changes in that respect, whereas the changelog of TrueCrypt (6.2) says: "The I/O pipeline now uses read-ahead buffering, which improves read performance especially on solid-state drives, typically by 30-50%".
To me, read-ahead buffering sounds exactly like "I read sectors ahead (of decrypting them/of waiting for previous sectors to be finished)".

[pepak]

CPU should be the limiting resource here, but it is not the case: Even when stressing the encrypted disk, CPU usage is around 30%, with spikes up to 50%, but never more.

Which CPU do you use? If one with two cores, then 50% means complete saturation of one core (the one that is performing the current encryption task).

Even if CPU really were free, remember that the necessary serialization of tasks means a much slower throughput even if all components have "free capacities".

I am wondering if Bitlocker, SafeGuard, and all the other tools performed any better with SSDs. I need disk protection, but like I said, I am not willing to spend 100 bucks for a tool that only delivers 40% performance.

You can only try. My experience leads me to belief that if you will measure the performance drop by benchmarks, you will see similar drop with all products.

This is what I don't get. Especially sequential reads should perform much better as there is still a lot of CPU available to do the decryption. I don't see other limits than CPU at all.

The data needs to be read from the drive, that's one delay. Then it needs to be decrypted, which is another delay. After that a new read can happen.

I know encryption tools try to paralelize this (read more data while decrypting the previous batch), but their success seems to be very limited, if any.

Did you use BCVE's internal benchmarks for this?

No, I measured real application performance (e.g. time needed for chosen tasks, including file copy and others).

Edit: PGP Full Disk Encryption had exactly the same problem and apparently they fixed it in the latest version.
They claim to have fixed. I have seen the same claim with BCVE and TrueCrypt.

[LindaLoo]

Interesting.

As it happens I gave PGP Whole Disk Encryption a try last night.  The trial is for version 10 that's claimed to resolve any CPU 'inhibiting' issues.  Here are the benchmarks:



 

My cpu usage was around 25%.

[fender]

Thank you for your fast replies. I understand that by using encryption I will lose performance. So it is like I said, CPU should be the limiting resource here, but it is not the case: Even when stressing the encrypted disk, CPU usage is around 30%, with spikes up to 50%, but never more. That's why I posted here in the first place.

Sorry for the confusion, I was not asking about different encryption ALGORITHMS, but different full disk encryption tools: I am wondering if Bitlocker, SafeGuard, and all the other tools performed any better with SSDs. I need disk protection, but like I said, I am not willing to spend 100 bucks for a tool that only delivers 40% performance.

CPU is one limiting factor, and the need to do a lot of tasks sequentially (first encrypt, then write) another.

This is what I don't get. Especially sequential reads should perform much better as there is still a lot of CPU available to do the decryption. I don't see other limits than CPU at all.

On the other hand, when I installed Windows 7 rather than XP, benchmarks almost doubled for all ciphers on identical hardware. Unfortunately, W7 were too unstable to use. So it seems the culprit is actually the disk subsystem of Windows rather than encryption software itself.

Now that is interesting. I've been using Windows 7 since the day it was released to our MSDNAA university network, and it quickly became my favorite Windows ever. I find it to be the most stable of all. Did you use BCVE's internal benchmarks for this?

Edit: PGP Full Disk Encryption had exactly the same problem and apparently they fixed it in the latest version.

After performing PGP Whole Disk Encryption on a computer with a solid state drive, system performance appears significantly reduced. In some instances the solid state drive performance may decrease as much as 50% when encrypted.
This is a known issue with PGP WDE on versions of PGP Desktop 9.x due to a current limitation of the AES engine. The degradation in performance of the solid state drive occurs as the PGP AES engine cannot keep up with the raw throughput of the disk.

[Jetico]

We would agree with comments of Pepak concerning CPU as limiting factor. During your tests please take a look at CPU usage in Windows Task
Manager. If it is close to 100%, BCVE, BestCrypt or other encryption
utility will not be able to write to your disk faster.

Please note also (as Pepak also mentioned) that RC6 is the fastest
encryption algorithm available in BCVE. You can compare performances
of the algorithms on your system by running 'Benchmark' command from
'Options' menu in BCVE program.

[LindaLoo]

Having just removed BCVE from my new Intel 160 2nd Generation SSD I can also confirm Fender's AS SSD Benchmark findings.

With encrytion:


After encryption removed:


(my benchmarks from before encryption are very similar to those shown afterwards)

I really don't want to lose such a significant level of performance when that's largely the point of using an SSD.

Would Best Crypt (not the Volume Encryption edition) be a sensible compromise to use for encrypting individual files/folders that require some security?

[pepak]

BestCrypt volume encryption costs over 60% of performance![/b] Using AS SSD Benchmark, a popular tool for SSD benchmarking, without encryption I get >220MB/s sequential read speed, with BCVE I only get ~88MB/s! Other benchmarks lose similarly. I understand that encryption takes its toll, but 60% is simply not tolerable. CPU doesn't seem to be the limiting element, while running disk benchmarks about 30% CPU is used.

Two things:

1) Yes, you will see a significant decrease of performance on many disk tasks when using encrypted volumes (and not just with BCVE, either).

2) Most real-world applications access the disks in such a way that is much less prone to performance degradation. In other words, you will see a much more servious slowdown in a benchmark than in, say, a text editor, video player or even a compression utility.

1. Why is it that it takes THAT much performance? Shouldn't CPU be the limiting element here, doing the en/decryption?

CPU is one limiting factor, and the need to do a lot of tasks sequentially (first encrypt, then write) another.

2. I'd be happy to assist in improving performance/testing beta drivers.

I very much doubt current encryption schemes can be dramatically improved.

3. Did anyone try other encryption methods in regard to performance?

Yes. On my computer, RC6 is the fastest, with AES and TwoFish trailing slightly behind it; Serpent gets about half the speed of AES.

On the other hand, when I installed Windows 7 rather than XP, benchmarks almost doubled for all ciphers on identical hardware. Unfortunately, W7 were too unstable to use. So it seems the culprit is actually the disk subsystem of Windows rather than encryption software itself.

4. Would it be possible to add an option to only encrypt used sectors in the first place? Writing all sectors of SSDs isn't recommended, 10% should be left unused at all times for their internal wearing level algorithm.

That's what TRIM is for.

[fender]

I am not convinced yet. If I encrypt all sectors, and this is transparent to the OS, why should Windows TRIM sectors that look unused? This is why I've used SDelete by Sysinternals to create a file that uses all free space and deletes the file afterwards, to make Windows send a correct TRIM command. Also, I've used the Intel SSD Toolbox to execute (additional?) TRIMs after encryption and after "wiping". There is a discussion as to whether the Intel Matrix Storage driver really passes TRIM commands to the drive or not, so I've also tried different device drivers (the stock Win7 driver, various Intel drivers). Unfortunately, there doesn't seem to be a way to know if the TRIM command really reached the drive, how the toolbox TRIM works and when exactly the drive recycles unused sectors. Which is why I also left the laptop running all night, in hope that it would perform cleanup when unused.

Still, the results are depressing: BestCrypt volume encryption costs over 60% of performance! Using AS SSD Benchmark, a popular tool for SSD benchmarking, without encryption I get >220MB/s sequential read speed, with BCVE I only get ~88MB/s! Other benchmarks (random read/write access etc) lose similarly. I understand that encryption takes its toll, but 60% is simply not tolerable. CPU doesn't seem to be the limiting element, while running disk benchmarks about 30% CPU is used.

1. Why is it that it takes THAT much performance? Shouldn't CPU be the limiting element here, doing the en/decryption?

2. I'd be happy to assist in improving performance/testing beta drivers.

3. Did anyone try other encryption methods in regard to performance?

4. Would it be possible to add an option to only encrypt used sectors in the first place? Writing all sectors of SSDs isn't recommended, 10% should be left unused at all times for their internal wearing level algorithm.

5. Also, for some reason, it takes VERY long (30 seconds or so) until a boot password is accepted.

System: Toshiba Portege M800, Intel Core2Duo P8600 2.4GHz, Intel SSD 80GB X25 Postville, 4GB RAM, Windows 7 Professional, latest BCVE (2.14.03).

[LindaLoo]

Thank you for the explanation, that's very helpful. 

[Jetico]

Performance of SSD disks will not be hit. If SSD disks like to get
requests to read or write data by 32 KBytes blocks, Windows becomes
aware of that. Hence, requests from Windows to read/write data
to such disks will not be less than 32 KBytes.

BCVE monitors all the requests. If the SSD disk is encrypted, BCVE
will change contents of the data buffer from the requests (encrypt
it if system writes data to disk, or decrypt it if system reads the
data).

Since BCVE works with a whole buffer of data from such a request,
it will NOT change the size of the buffer sent to SSD disk. I.e.
SSD disk will get the same size of data to write or read from the
disk as if BCVE were not running at all. So performance of the
operation will not be affected (of course, except the time
necessary to encrypt or decrypt data buffer).

[LindaLoo]

As I'm considering the purchase of an SSD drive and I'm a BCVE user, I was very interested to read this thread.  Unfortunately I don't fully understand the technicalities and, in particular, your reply to pepak's original post regarding the potential for a 98% performance hit.  Are you saying that yes, the performance would be hit by this amount or no it wouldn't?!  Sorry! 

[Jetico]

BCVE should not have a negative effect on SSD drive lifetimes. First,
the software does not remove or change in any way the TRIM commands
sent by OS to SSD disk controller. Second, BCVE does not run any
additional read or write operations on the SSD drives (of course,
except initial encryption process).

In simple words, if Windows informs SSD disk controller that 200
sectors starting from sector 10000 are not in use (what TRIM command
does), this command will reach SSD disk, whether it is encrypted by
BCVE, or not. If Windows decides to send command to SSD disk to write
sector number 2560 with buffer of data, BCVE will just encrypt data
inside the buffer and let the command to run on the disk.

[teethree]

Does Jetico have any information if BCVE has a negative effect on SSD drive lifetimes.

I'm not sure from the posts above if the results of the TRIM command being executed (automatically by the OS in the case of  Windows 7), perform actions on entire blocks because of BCVE being used and thus degrade cell lifetimes more than would be the case on an SSD without BCVE in use.

Could Jetico Support provide some further information on this area please?

[Jetico]

 When the drive erases some unused blocks before writing to them, or when the TRIM command is used, will those erased memory blocks (and free sectors in partially written blocks) remain empty or will BCVE force them to contain scrambled data?

Erasing unused blocks by SSD drive happens on the level of the drive
hardware controller. TRIM command comes unchanged directly from
filesystem driver (like NTFS driver in Windows 7) to the hardware
controller.

Then the hardware reads and erases the blocks as you have described,
so that when next write operation occurs for the block, there won't
be a need to read and erase the block prior to the write operation.
(And performance of the write operation will be increased.)

BCVE does not participate in the erase operations happened inside
SSD disk controller, so encrypting SSD disk should not degrade
performance of its write operations.