TrueCrypt 6.2 with SSD optimization

[Diapolo]

See here: http://www.truecrypt.org/docs/?s=version-history


The I/O pipeline now uses read-ahead buffering, which improves read performance especially on solid-state drives, typically by 30-50%. (Windows)

Download: http://www.truecrypt.org/downloads

Perhaps someone wants to try that :).

Dia

[m.oreilly]

hehe, you devil you. tempting it is...

[HDCHOPPER]

LOL go for it Dia ....

[m.oreilly]

arg, it balks @ my win7 rc...which is probably a good thing. can set 'compatibility mode', but don't want to goof it up atm...

[MikhailT]

Not for macs. I was willing to try it. Oh well.

[Sukrim]

http://www.truecrypt.org/downloads --> Mac OS X

:rolleyes:

[Ledward]

It's a Windows-only improvement. Look on the changelog.

[MikhailT]

http://www.truecrypt.org/downloads --> Mac OS X

:rolleyes:

I was talking about the read-ahead buffering feature, it's for Windows version only.

[DoiNkk]

I would love to hear more about this from people with vista x64 :)

[Jukken]

Encrypted my XP32 raid0 setup with Truecrypt.

Unfortunatly my cpu is the botteneck, it can only cope with abit more then 200MB/s encrypted (AES).

[Halk]

I wish you'd input your system details Jukken! What kind of CPU do you have?

And will TrueCrypt use multiple cores?

[Diapolo]

I wish you'd input your system details Jukken! What kind of CPU do you have?

And will TrueCrypt use multiple cores?

I can answer your second question: Yes, since version 6.


Parallelized encryption/decryption on multi-core processors (or multi-processor systems). Increase in encryption/decryption speed is directly proportional to the number of cores and/or processors.

For example, if your computer has a quad-core processor, encryption and decryption will be four times faster than on a single-core processor with equivalent specifications (likewise, it will be twice faster on dual-core processors, etc.)

Dia

[minimal]

I'm running Truecrypt 6.2 on Windows 7 x64 (7100) without problems. I was running version 6.1a as well, no issues. There is a warning on install that Windows 7 isn't supported yet but it installs fine.

[m.oreilly]

I'm running Truecrypt 6.2 on Windows 7 x64 (7100) without problems. I was running version 6.1a as well, no issues. There is a warning on install that Windows 7 isn't supported yet but it installs fine.

what does task manager look like as far as cpu activity?

edit: and did you use it on the os drive?

[Sukrim]

I wish you'd input your system details Jukken! What kind of CPU do you have?

Most likely something around an Athlon X2 4850e/C2D 4400...

Here's a german site with loads of benches for Truecrypt performance.
http://www.computerbase.de/news/software/sicherheit/2008/juli/truecrypt_60_benchmark/

[minimal]

what does task manager look like as far as cpu activity?

edit: and did you use it on the os drive?

I have never noticed any extra CPU usage. Although the encrypted partition isn't my main OS drive.

[haus]

Seems fine here (XP32, single encrypted c: partition on Vertex 60 with not-the-latest FW). I know it's unhelpful to say I don't run benchmarks...but at least the upgrade from 6.1a went just fine and I need to go create my new rescue disk. I can't say if it's faster; if so it went from ludicrous speed to ridiculous speed.

[DoiNkk]

As soon as my video card gets back from RMA, I am going to be trying this out with Vista x64.

[Jukken]

Core 2 Duo E6850 (@3.2GHz).

Truecrypt is fully multithreaded...wish I had a quad-core...

[Aesma]

Hello :)

I'm looking to buy a SSD, probably a Vertex or Agility 120GB.

I'm considering using it with a Truecrypt encrypted system.

I followed the SSD tech for two years now, read a lot on this forum (I thought I was already registered but can't find my username).

I see a problem with using TC encryption on a SSD : it fills the empty space with encrypted "nothing". So, the SSD is 100% full, wich is not good for performance, but even worse for durability, if I understand correctly how the wear levelling works. Moreover, the "trim" function can be of no use. It is possible to let a part of the SSD blank by not partitioning it, but I don't know if the wear levelling will use that.

What do you think of my thoughts ? For those on this thread who use a SSD & TC, is your SSD OK ? And perfs ? Being limited in max read/write is not a problem for me, I have a quad core and don't really mind about sequential speed anyway. I wonder if the access time are still good, also ?

[dpwrdpwr]

i started to encrypt whole drive but changed my mind.... is there anyway to cancel encryption process ? it only let's me pause it but it always asks me to resume... or do i have to wait until it's done and then decrypt it ?

[stbrock]

I can report excellent experience with TC 6.2 on encrypted file volumes of 4 to 25 GB on Vista x64 (i7 quad and ASUS P6T) and on XP Pro (various desk and laptops). Previously, the performance hit (per ATTO) was variable, sometimes small, sometimes up to 20 to 30 percent. Afterwards on 6.2 reads and writes were both consistently within 5% of native, sometimes reported by ATTO as virtually identical, presumably a measurement artifact.

Same experience on an early Core 60 GB and Vertex 120 (with original firmware). Haven't rechecked on 1.3 firmware as it still feels fast. I haven't used full disk encryption, but encrypted volumes now have virtually no penalty as far as my subjective experience. For example, I can put a 200 MB encrypted volume on Dropbox and run Firefox Portable off it and it feels very speedy.

[Aesma]

This is good info, thanks. From what I understood about GC, it will work even in my case.

[woekele]

Just wondering if anyone can confirm... Will garbage collection/trim still work and keep the disk fast, even though fully encrypting the drive with truecrypt?

With the text from Aesma in mind:

I see a problem with using TC encryption on a SSD : it fills the empty space with encrypted "nothing". So, the SSD is 100% full, wich is not good for performance, but even worse for durability, if I understand correctly how the wear levelling works. Moreover, the "trim" function can be of no use. It is possible to let a part of the SSD blank by not partitioning it, but I don't know if the wear levelling will use that.

[Aesma]

I just got my SSD and will be encrypting it soon. For trim it is certain it will not work, TC will not let it pass (I hope), if it passed it would mess up the thing, because there is no free blocks with TC, they all are data.

[woekele]

By the way, a fair warning: I messed up my windows while having my drive encrypted and it took 3 full days for the 60GB drive to get decrypted in rescue mode. But hey, I got my data back from it ^^

[Aesma]

What is your CPU ? Did you use cascaded algos ?

[woekele]

A p7350 (2x 2Ghz) and I just used the defaults (AES I think?)

It said in the rescue screen that decryption would have been faster while in the OS, but I couldn't get into the OS anymore and didn't have any other PC at hand. So I waited 3 days for the decryption and then ran a windows repair installation when it was done and here I am :)

[woekele]

I have a 120GB Vertex and a 100GB partition on it, 20GB is left free (unpartitioned). I installed windows 7 to the 100GB partition. I then encrypted this system partition with truecrypt.

Instead of 215/145 I now get about 80/80 sequential read/write in crystal mark. But it still 'feels' fast, so I find it no problem. And if my laptop gets stolen, noone can access my precious datas! I don't have anything special on it, but I'm just paranoid :D

[Domdom]

My Vertex 60Gb is fully encrypted and no issues so far. Still in FW 1.3 but WIPER works normally. System is fast although I havent tested it in details.

[IceFire122]

Hi,
no noticable speed decrease with my PC.

BUT some important tips about True Crypt:
True Crypt fills all available blocks on a partition to cloak, which blocks are really written. So, even during delete, these blocks will be filled with random data.
This means two things:
1. These blocks can never be trimmed. Maybe trim commands never reach the SSD.
2. Empty blocks inside True Crypt cannot be used for wear levelling, until True Crypt decides to store new data in them. So, the only blocks usable for wear levelling on the SSD side are the reserve block. This behavior ist similar to having a nearly full SSD without true crypt and your reserve blocks will wear out sooner. With a full disk, this is no problem, because you simply won't write a lot of data on it (without deleting something).
But a True Crypt partition only seems to be full an will still recieve lot o data. True Crypt will release specific blocks with random data in order to store real data in it. Hence, it is possible (but unproven), that True Crypt can hinder wear levelling to a certain degree.
In my beginning configuration (all partitions encrypted), i found the erase counters going up fast. For the firm ware the SSD seemed to be full and it was only allowed to work with only the reserve blocks

How to help performance and wear levelling at the same time:
1. Reserve some unfilled space on the SSD by
a) having some unpartitioned space in combination with partition encryption or
b) (the better way IMHO) using a size variable container file on you data partition.

The latter solution means, that your SSD speed will stay up, until you really fill the drive with data. Also multiple writes and deletes have a lot of blocks to "play" with.
Unfortunately, size variable containers cannot shrink by themselves. So, if you ever fill your data partition to the max, this solution will not recover even if you delete big amounts of data.
The work around: Backup the data, kill the big container and start again with a smaller one.

2. Use GC instead of TRIM firmware. Doing so enables the firmware to work with all blocks not yet claimed by truecrypt and your write speed will stay up.

Doing 1.b) and 2. is working fine for me. And my erase counter is going up with a more reasonable speed, like 100 writes per month=>100 months/8 years of live.
One last remark, by limiting the block use of truecrypt, your system might be easier to attack. But IMHO, this problem will be solved, by the SSDs wear leveling filling all empty blocks with data evenly.

I hope, I could explain this complex matter enough. It took me some time to understand it myself, since not many users work with SSDs and disk/partition encryption until now, or they wear out their disks fast without noticing.

Greetings,
IceFire

[IceFire122]

My Vertex 60Gb is fully encrypted and no issues so far. Still in FW 1.3 but WIPER works normally. System is fast although I havent tested it in details.
With full disk encryption, I think, WIPER will not work properly, but only appers to do so.
WIPER checks the file system for empty blocks and sends them to the firmware. But in a True Crypt file system, there are no real empty blocks.
Either True Crypt tells WIPER there are no empty blocks or it blocks the WIPER messages to the firmware. Whichever happens depends on how low level WIPER is accessing the disk/partition.

On the other hand, wiper never broke something on my PC, which is okay, too.

IceFire

[Domdom]

Wow IceFire122 this is a very interesting answer. I dont know really what to do, Full Disk Encryption is a must in my company.
Since my Vertex is only 60GB, it is hard to leave empty space untouched! So your recommendation would be FW 1.4 GC not TRIM?
What you say with Wiper and no empty space make sense!
So are SSD users in trouble with FDE and wear levelling?

How do you figure out the erase counter?

[IceFire122]

1) I dont know really what to do, Full Disk Encryption is a must in my company.
2) So your recommendation would be FW 1.4 GC not TRIM?
3)So are SSD users in trouble with FDE and wear levelling?
4)How do you figure out the erase counter?

Hi,
1)-3) If you have to use FDE, you should use FW 1.4 GC and crypt the whole disk.
But, you also should accept, that:
a) Your write speeds are slow. For a small packages, a large block has to erased (write overhead). On the other hand, GC should be able to pre-erase reserve blocks and speed up the process a bit.
b) Also because of write overhead, small data packets wear out and fragment the disk faster than an uncrypted one.

True Crypt is not yet really adapted to SSDs and probably will not be anytime soon. Because, if you don't store random data in empty cells, it is slightly unsafe/unsecure for attacks.
Does your company use True Crypt or one of the professional solutions. With a professional solution, we will probably see better SSD adaption at a later stage. True Crypt is geared towards private users (according to the developers).

4) With CrystalDiskInfo, the smart values of OCZ SSDs can be read out (there is a guide in this forum). The Value D0 is called "Average Erase Count" and shows exactly? that. Of course, this development is pretty new and nobody can tell you about the reliability of such values.
Value CD gives you an average fix live expectation of your cells (10000 dec=>2710 hex). D1 (Remaining Drive Life) is thought to be calculated by 100-(CD/D0*100).
So, 100 averages per month gives you roughly 100 months of use before the drives cells begin to fail.

Greetings,
IceFire

[Domdom]

Hi,
4) With CrystalDiskInfo, the smart values of OCZ SSDs can be read out (there is a guide in this forum). The Value D0 is called "Average Erase Count" and shows exactly? that. Of course, this development is pretty new and nobody can tell you about the reliability of such values.
Value CD gives you an average fix live expectation of your cells (10000 dec=>2710 hex). D1 (Remaining Drive Life) is thought to be calculated by 100-(CD/D0*100).
So, 100 averages per month gives you roughly 100 months of use before the drives cells begin to fail.
Greetings,
IceFire

All of this is clear, you seem to know what you are talking about ;)
What kind of units are used? like for D1? Thanks Win7 for this hexa calculator!
D0 : 5EF
D1 : 63
CD : 186A0

Am I in trouble :) drive seems ok

[IceFire122]

D0 : 5EF
D1 : 63
CD : 186A0
Am I in trouble :) drive seems ok

About your numbers:
CD: 186A0 hex = 100000 dec. It means, the average life time of a cell is set to 100.000 cycles (erase cycles). This is/was the standard for FW 1.3. With FW 1.4/1.41, it is changed to 10.000, which is closer to the real life expectancy of MLC disks. Only SLC disks are thought to have 100.000 cycles.

D0: 5EF hex = 1519 dec. It means, all of your cells have already been erased 1519 times in average.

D1: 63 hex = 99 dec. You have 99 % of your drive live left. BUT, if it is an MLC drive (Vertex?) and you flash to 1.4 or 1.41, the calculation will change because of the changed CD-Values. After flashing, the D1 value should change to 55 hex = 85 %.

If you want to calculate the remaining drive life in months, you can approximate by:
drive-age in Months/15*85=remaining months

Of course, the CD and D1 values are best guessed by the firmware. Not all cells will fail at 10.000 cycles, but some might. The drive will still be usable after some cells are failing. Also, the calculation might be limited to some blocks (reserve blocks) or not. So, if you change your usage of the drive, it might last longer...
One big advantage of SSDs: They can predict their remaining life better than HDD and you should be able to get your data back after cell failure.
Flash-NANDS fail while erasing them, not while writing or reading data.

Greetings,
IceFire.

[Domdom]

I recently encrypted my SSD with Truecrypt so here we go with benchmarks:
1.41 GC without TC:
http://img189.imageshack.us/img189/5676/benchdiskmark241109fw14.jpg (http://img189.imageshack.us/i/benchdiskmark241109fw14.jpg/)
Nice!

Now with TC full disk encryption:
http://img685.imageshack.us/img685/6706/benchdiskmark040210fw14.jpg (http://img685.imageshack.us/i/benchdiskmark040210fw14.jpg/)
Not so good, still ok though

I have no choice but to encrypt but is there a way to improve it? PC stays idle at night (logged on) so GC should kick in and wiper once a week ...
I would have expected WRITE to go down not READ