[Discuss] TrueCrypt with SSD

[Chuck Anderson]

On Fri, Aug 12, 2011 at 09:30:30PM -0400, Chris O'Connell wrote:
> I bought my boss a really awesome computer and specifically wanted to use an
> SSD for the many benefits (sound, speed, power consumption).

Which one?  I compared the OCZ (and all the other SF2281-based ones)
vs. Intel 510 (marvell-based) and decided on the latter for Intel's
better stability & Q/A testing, etc. over the higher performance but
horror stories of frequent lockups and firmware issues of the SF2281
SSDs.

> Before encrypting the drive using trusty TrueCrypt I did a little googling.
>  I found that full disk encryption significantly decreases performance.  I
> also found on TrueCrypt's website a statement telling users who have wear
> leveling drives (using TRIM) that TC should not be used.  TC claimed that
> their program could not be guaranteed to work properly.
> 
> Has anyone had any experience with this?  Thoughts?

Going through this myself now.  From my research (no experience yet)
TrueCrypt is correct in what they say.  The problem is that many/most
full disk encryption systems will not issue TRIM/discard for unused
blocks.  They don't want to distinguish to the lower block layers
which blocks are unused, because that would give away information
about the encrypted data (namely, which blocks have valid encrypted
data, and which are unused).  This could theoretically be used to
perform known-plaintext attacks against the encrypted data, especially
if certain filesystem structures are made apparent by the pattern of
used/unused blocks.

Secondly, most FDE systems want you to randomize the whole disk before
encrypting.  This is done to also hide which blocks are being used for
real encrypted data.  Once you do that on an SSD, however, the SSD is
fully "used" from its own perspective, so it doesn't have any empty
space with which to perform wear-leveling and parallel writing for
NAND flash longevity and performance.  There is always some "spare"
space that the SSD reserves for this purpose, but consumer SSDs don't
have as much of this spare/hidden space as enterprise SSDs.

Thirdly, with SSDs you have to worry more about "deleted" data.
Whereas on a spinning HDD you can overwrite unused or deleted data
sectors with a high degree of certainty that the data is really gone
(excepting when the drive remaps a bad sector to a spare sector), on
SSDs this is virtually impossible to achieve due to the wear-leveling
techniques in use.  Some SSDs have built-in AES encryption to mitigate
this issue, but you have to trust the vendor to get the encryption
right because none have so far opened up their systems to scrutiny by
independent labs.

These problem also exist with dm-crypt/LUKS-based encryption.  I'm
still researching to find out for sure, but I believe the basic Linux
device-mapper layers (for LVM support etc.) have support for TRIM now
in the newest kernels.  However, this hasn't made it into dm-crypt yet
for encrypted devices.  Teaching dm-crypt to TRIM would trade some of
the security for performance and longevity of SSDs.  Many who have
SSDs think this is an acceptible tradeoff and I agree with them, but
it isn't there yet.

Don't forget to align your entire block device stack (partition
beginnings, LVM offsets, LUKS offset, filesystem) with the erase-block
size of the underlying SSD.  If you don't do that, your performance
will suffer and your SSD will wear out faster.  The newest Linux
distros have the latest tools which will do this for you mostly
automatically, but it is worthwhile to check to be sure everything
came out right.