# Can TrueCrypt encrypt SSDs without performance problems?

I am running windows 7 prof on a SSD (mSATA). My CPU i7-3610QM has AES-NI-support. I want to encrypt my SSD with truecrypt with AES. But I am really unsure if this is a good idea because of (a) the performance and (b) the lifetime of my ssd.

About (a) I think, encryption works with 3 gb/s because of the AES-NI. So this should be fast enough for SSD-encryption, right?

I heard, that using the full space of a SSD is a bad idea. Nevertheless, I did this. The full 120 GB are formatted currently as my system filesystem. Do I "destroy" my SSD with a full system encryption (so pre-booth-authenticatio is required)?

What does happen with the first 100 MB marked in Disk Management with "System Reserved"?

• You didn't say what model SSD you have, but several now support on-drive full-disk encryption that is TCG Opal compliant. Because that works at a lower layer than TRIM and erased block tracking, it doesn't reduce lifetime nearly as much. – Ben Voigt Jun 16 '14 at 4:17
• My SSD is SAMSUNG PM830 (MZMPC128HBFU). – tjati Jun 16 '14 at 7:08

Hard disk encryption is not supposed to alter SSD life time: "encrypted" bits are not harder to read or write than "normal" bits, and (properly done) encryption does not enlarge data. Indeed, the SSD device has no idea whether what it is asked to read or write is encrypted or not. One megabyte is one megabyte.

(Edit: about "encrypting empty space": this implies only one write pass of the whole disk area; this needs not be done regularly, only once. Flash memory can be rewritten about 10000 times before failing, so this extra encryption should not shorten the SSD lifetime by more than 0.01% -- not enough to be detectable.)

The current state of TrueCrypt being what it is (the "official" software has all but disappeared), it is hard to get definitive answers, and even recommending TrueCrypt can now be a matter of delicacy. Thus, claiming that TrueCrypt will or will not use AES opcodes can be too bold a statement. This article says that, back in 2011, TrueCrypt 7.0a supported AES-NI, and could follow the speed of a SSD (at least the SSD they used for the benchmark).

Performance, in general, is a matter of measurement and should be benchmarked rather than discussed; especially for something as fuzzy as "general computer performance" from the point of view of a human user: the user's feelings are as important as raw figures. The main perceived boost from a SSD comes from the much reduced latency more than from the raw throughput for single-file I/O. We can still speculate that AES-NI allow for more than 1 Gbyte/s raw encryption speed on a 2 GHz CPU; thus, half a core worth of CPU ought to be enough to follow the throughput of a decent SSD (my SSD runs at 500 MB/s and I find it decent enough).

Of course, installing a whole-disk encryption system has the potential, in case of some stupid incompatibility with your OS and/or BIOS booting system, to make your machine unbootable. Make backups ! And prepare a "recovery disk".

• Ok, I added some precisions on that point. – Thomas Pornin Jun 15 '14 at 19:43
• Actually, filling the disk with uncompressible data will decrease its lifetime severely due to write amplification. SSDs rely on keeping as many blocks in the erased state as possible, that's why the TRIM command was developed. – Ben Voigt Jun 16 '14 at 4:11
• But when I encrypt my full ssd, I remove the the recommend space of 10%-20% a ssd should always empty (in the view of the ssd). Is this a problem? – tjati Jun 16 '14 at 7:09
• Also, make encrypted backups. – lorenzog Jun 16 '14 at 11:18

When using disk encryption, the data is encoded before being written and decoded before being read. The encryption/decryption happens on the RAM rather than the SSD itself so in reality there is no extra read/writes apart from the metadata used for the encryption layer which is negligible.

Synetech made a graphic on Super User to illustrate this:

*Note: if for any reason, the OS or the software causes the data to be encrypted in big chunks, the above statement is no longer true. Suppose it encrypts 4K at a time, then simply modifying a byte will cause writes to 8 512-byte-blocks to SSD, while without encryption, OS (if it optimizes well) only needs to write to 1 512-byte-block. To address this issue I would recommend (if possible) to configure the software to use a data chunk size that fits best according to your data.

Also, if the disk controller uses data compression (some SSD controllers like SandForce use this to improve read performance), then enabling encryption will reduce the lifespan of the disk.

Real-time performance impact from encryption will vary depending on the type of disk, the average size of files stored on the disk and the algorithm used for encryption. However based on the benchmarks on http://anthonyvance.com/blog/security/ssd_encryption/ the performance impact is definitely significant. How much you will notice this in real life usage is another story.

Here is a benchmark from MediaAddicted:

Some have guessed that these results are due to the way TrueCrypt handles writes to the SSD, which prevents TRIM commands from reaching the SSD controller at all and thus having no (positive) effect on drive performance degradation over time; Although I have not seen actual proof for this theory.

• If you use screenshots from other websites please include the source. This could otherwise be considered as plagiarism. – Lucas Kauffman Jun 15 '14 at 18:16
• When you take content from someone, you must acknowledge it. Plagiarism is not cool. – Gilles Jun 15 '14 at 18:17
• Thanks Lucas for the heads up :) I added the source, if there's anything else please let me know :) – Abbas Javan Jafari Jun 15 '14 at 18:22
• Do not edit out attributions. It's illegal. – Gilles Jun 16 '14 at 9:38
• Abbas - just for future reference, the type of attribution Gilles edited in is what we would want any time you use content from an external site. And this content includes text or images. Just add the link and reference and we're good. – Rory Alsop Jun 16 '14 at 19:23

I think one big issue of SSDs is that they can't overwrite a block so every write will result in a erase + write operation. To improve the performance a SSD controller will just write to an empty block and erase the old block later. But if the SSD is full this will not be possible and performance drops.

This is discussed here: https://superuser.com/questions/162155/does-low-disk-space-affect-ssd-performance

If you decrypt a volume with Truecrypt, from the controllers point of view you have a full partition filled with garbage that fills up the whole space. You access your data via a virtual volume that knows to to read (decrypt) the data.

Without having benchmarked this, I would argue that a whole SSD decrypted with Truecrypt will impact performance and it would be a good idea to leave 15% of the space empty. But than again that totally depends on your SSD controller and how good it can handle full disks.

Assuming you have not started yet, you can shrink your boot volume with gparted live-cd http://gparted.sourceforge.net/livecd.php

In order for the TRIM function to operate properly, and allow the garbage cleanup programmed into the SSD to operate effectively you would want the free space to be transparent to the drive. I do not believe that TrueCrypt will allow for this without proper configuration, at that point you would need to optimize your OS to disable classical hard disk maintenance.. Without TRIM support enabled, the SSD sees empty space as used space and it can not use it for it's life extending wear leveling and it will use the spare sectors. When those start to wear out, your drive will start to have failures.

Linux has a very similar method for full drive encryption known as sd_crypt. This software is well-maintained and allows options such as "allow-discards" that will provide transparency of free space and allow the TRIM and garbage collection to work as it should with a price of decreased security. Unfortunately sd_crypt is for the *nix OS.