Hacker News Reader

Hacker News

Comment by mike-cardwell | Hacker News Reader

Parent Full thread

mike-cardwell

There's nothing stopping you using FDE on an SSD...

View on HN

http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.ht...

FDE on a SSD negates the gained speed advantage

Does it? Even if you have a CPU with AES-NI instuctions like an Intel Core i5 or i7?

unfortunately yes, see http://blog.siyuz.net/2010/11/17/truecrypt-7-0a-fde-on-ssd/#

I encrypted my SSD using BitLocker, and for me, the performance hit is not really noticable in my day-to-day work (programming + running a virtual machine). Your SSD will still be A LOT faster than a regular, unencrypted HDD. But YMMV.

This case is only relevant to SSDs with a sandforce controller, however -- as (only) the sandforce controller compresses data for increased speed, which cannot be done with encrypted data.

there's some scenarios where it may not be too bad. From what I've read I'd agree that truecrypt on an SSD doesn't sound like a good option. Bitlocker seems possible if you're running Win7 (ultimate or enterprise).

One other thing to watch out for with SSDs is the "native" AES encryption. From what I've read in many cases it's only there to provide a fast wipe facility and doesn't actually provide protection for data on a lost laptop. Some SSDs (eg Intel 320) provide password protection for the encryption keys via the ATA password, but a bit of reading didn't make me feel too comfortable with how they've implemented it.

That's not what I've seen, at least for FileVault 2 under OS X Lion. I'm using a 2010 iMac with a third-party SSD, and a 2011 MacBook Air with Apple's stock SSD. Both computers are blazing fast at disk access, even with full-disk encryption enabled.

If you're confident you're encrypting all your data, then you're still way above average. The nice thing about FDE is that I can "set it and forget it." I don't have to think about which files belong on which partition anymore. It's all safe.

As far as I can tell, the only problem is that the encryption layer won't forward TRIM commands to the SSD by default because that can reveal some information about the data layout. I've been using full disk encryption on an SSD for a year and while the write speed got somewhat slower over time, it's still better than a hard drive, and overall the system feels responsive. At the rate the cost/GB drops, I was intending from start to replace it after two years or less.

But here's the thing: If you use Linux with dm-crypt, you can set it to pass TRIM commands to the disk. It seems pretty safe, it's only that it will leak information about which blocks are actually used.

LE: Here's how to do it: https://wiki.archlinux.org/index.php/System_Encryption_with_...

I ran some benchmarks and 4K read speed really takes a hit with FDE:

2xWestern Digital blue label RAID 0 : 0,65Mb/s (for refrence)

Crucial M4 without FDE : 19,07 Mb/s

Crucial M4 with FDE : 5,59 Mb/s

however the benchmark shows that a SSD is still substantially faster than a classical RAID 0 array

Not enough information to verify the usefulness of your benchmark. Were the volumes/partitions aligned? What technology/cipher/keysize did you use for the FDE? Does your CPU have the AES-NI instructions? Does the encryption tech that you're using take advantage of those instructions?

FDE on any type of media causes no slow down if the CPU can encrypt/decrypt at least as fast as the disk can transfer data. It's not correct to say that FDE always causes slow downs.

Reply on news.ycombinator.com