SSD and system encryption

Topics: Technical Issues, Users Discussion
Jan 12, 2015 at 11:32 AM
Hi,

I'm planning on making a new PC in which the SSD will be a Samsung 850 Pro (256Go).

The documentation in not precise enought for me so I have a few questions :

1 - The documentation says about the Trim that "VeraCrypt does not block the trim operation on partitions that are within the key scope of system encryption".
Ok, the Trim is not blocked, but does it work ? Because this function replace bad sectors by good one when detected, but can they be detected with the encryption ?
Because in some posts I saw so that SSD's life was highly reduced when the system was encrypted (I saw that for Truecrypt, no information about that for Veracrypt).

2 - I don't fully understand the problem with Wear-Leveling : is it dangerous for the SSD life to encrypt the whole SSD or is it about the security leaks that may occurs ?

3 - Is there some benchmark available showing the performance before/after a system encryption ? I will use a MSI Z97 gaming 7 mobo, I7 4790k and 2x8Go DDR3 ram so I think I will not feel any lag, but I would like to see some tests about that.

4 - The same about Encryption and Hash Algorithms, I'd like to see a benchmark showing the difference in the performance of all the possibilities, about the rapidity and the security of the choosen solution.

Thank you in advance.
Jan 12, 2015 at 8:10 PM
Edited Jan 12, 2015 at 8:35 PM
The problem is about security - if you don't use a full SSD encryption.
http://www.zdnet.com/article/ssd-security-the-worst-of-all-worlds/
I don't fully understand the problem with Wear-Leveling.
There isn't really a problem. Once the disk is encrypted, the disk will get the same ammount of IO during normal operation, as a none encrypted one.
The the disk is encrypted, will not cause more IO or more wear on the disk. (Page file can cause waring, so if you have 16gb memory, then switch the page file OFF)

Speed wise, an i5 with AES can do 2.9gb/sec (in memory) Twofish still does 450mb/sec - which is still way more than the SSD can perform.
So you will not notice any issue.
Jan 12, 2015 at 8:57 PM
You should always turn off hibernation AND pagefile.. This is the quickest(instant) way to the resolve of the passwords from TC(Perhaps also VC).

http://www.lostpassword.com/kit-forensic.htm

I have turned all of that off, just in case :)
Jan 12, 2015 at 9:41 PM
You don't need to disable hibernation and/or the page file if you're using Full Disk Encryption / System Encryption, since both files will be written to the encrypted disk anyway. Unless of course you changed the location of the swap file to another, non-encrypted drive (which you can't do for the hibernation file as far as I know, it's always on your system partition).*

Turning off the page file will also create problems with a few programs, even if you have 16+GB of RAM. Some simply demand it to be there...



*
Regarding your link, see this section: http://www.lostpassword.com/hdd-decryption.htm
It can only extract the passwords from the hiberfile.sys if the file is actually readable, which it isn't if the whole disk is encrypted to begin with.
Jan 12, 2015 at 10:04 PM
Yes, I know... But what about running systems like serveres? Ofc I am running also with unmounted encrypted containers, but what if they somehow they got the page/hibernate files that way, and the passwords was stored in it? Better safe than sorry.. I haven't had any issues running without the pagefile for more than 8 years...

Mabye I am paranoid, but who cares :)
Jan 12, 2015 at 10:26 PM
Thank you for the link AlbertJohn I understand the problem now. But I will not have security issues because I want to fully encrypt the SSD.

I knew about the problem with the hibernation and page file, I will disable those features and see what happen to the system, if the pagefile is really needed I will turned it back on.

But the biggest question now is about the trim, does it or does it not work with a fully encrypted system and is there a change in the SSD life ?
Jan 16, 2015 at 8:45 PM
up ?
Jan 16, 2015 at 9:56 PM
thedeadman wrote:
Thank you for the link AlbertJohn I understand the problem now. But I will not have security issues because I want to fully encrypt the SSD.

I knew about the problem with the hibernation and page file, I will disable those features and see what happen to the system, if the pagefile is really needed I will turned it back on.

But the biggest question now is about the trim, does it or does it not work with a fully encrypted system and is there a change in the SSD life ?
.

See the documentation to get the answer to your questions.

https://veracrypt.codeplex.com/wikipage?title=Trim%20Operation
Jan 26, 2015 at 2:45 PM
destrukt wrote:
Yes, I know... But what about running systems like serveres? Ofc I am running also with unmounted encrypted containers, but what if they somehow they got the page/hibernate files that way, and the passwords was stored in it? Better safe than sorry.. I haven't had any issues running without the pagefile for more than 8 years...

Mabye I am paranoid, but who cares :)
What about servers?

If the entire system volume is encrypted and the system is hibernated then the system with an encrypted system volume would be protected since the hibernation file is also encrypted. Likewise if the system volume is not encrypted then the hibernation file is not encrypted and is vulnerable to this sort of attack. In either case an encrypted container is safe since you have to provide the password in order to mount it ( unless you specifically choose to automatically do this and bypass certain precautions in order to do so ).
May 25, 2015 at 11:53 PM
AlbertJohn wrote:
The the disk is encrypted, will not cause more IO or more wear on the disk. (Page file can cause waring, so if you have 16gb memory, then switch the page file OFF)
Don't. Windows is a paging OS, the memory management developed with the assumption that a pagefile will be available. Turning it off will be probably be fine most of the time, but once a hungry applications starts gobbling up and Windows runs low it will a) become much less responsive (due to shifting mempages like crazy and trying to "work" within the constraints and b) at some point start to throw small bits and pieces of swapped memory to the disk. As it has no declared pagefille, it will piss them all over the hard disk.

This will very likely be hard to notice in this case, with a low latency SSD to mop up the mess. It was hell to observe in the times of spinning rust disks. But even today, from my observation, even on systems with a LOT of RAM it is better to designate a small pagefile with a fixed size (select minimal size 4096 and maximal 4096 as well to set it up). This was the ideal solution for spinning rust disks, as it kept the page space within a continuos file with no delays for disk seek, but even in SSD times, I feel it keeps the system running smoother.

TL;DR: Turning off pagefile does not prevent paging totally. Keep a paging file set up. The wear on a SSD due to paging is negligible on todays high RAM machines.