[dm-crypt] Cryptsetup and SSD

Arno Wagner arno at wagner.name
Sat Aug 11 04:01:23 CEST 2012

On Fri, Aug 10, 2012 at 05:49:49PM +0200, antispam06 at sent.at wrote:
> How reliable can be the full disk encryption on a SSD, given the
> methods emplyed by the drive to prolounge the drive's life?
> Cheers

Reliabilility is not an issue. An issue is how reliable you can wipe 
an encrypted partition. With dm-cryot: Same as ordinray data, i.e.
if you overwrite it it is gone, if it goes into the free-pool, it
is still there. Hence on an SSD, protecting the key is your only 

With LUKS: Here the question becomes if the anti-forensic stripes
are depeted in key-change or on header-wipe. Basically, if just
one 512B sector for each used keyslot is zeroed, you should be 
pretty secure. Keyslot size for default parameters is just 
128k for XTS mode 256k. That may mean they end up completely
in an SSD block. And that in turn may mean they do not get
wiped at all, although SSD-blocks put into the "free" pool
should be zeroed very soon, otherwise there is no point to that
pool. SSD blocks can also go into the "defect" pool, but that
should be rather rare.

That said, if you want to be more secure, a ATA "secure erase
unit" command should erase everything, including free and defect
blocks, but YMMV as vendors may not implement that command 

Larger key-slots would also help, but cryptsetup does not
support setting them on luksFormat (yet) and you would have to
set them to large enough to be sure they do not end up in
the "free" or "defect" pool. For example, for a 240GB SSD,
you would need to use key-slots > 16GB in size. That may
be beyond what the libraries for cryptsetup can handle.
Just out os curiosity, I made a version of cryptsetup with
LUKS_STRIPES set to 400000 (i.e. 12MB keyslot size) and that
seems to work, including failure to open when I change a bit
towards the end. But I have no idea what the upper limit

Here is what I would recommend: If you can protect the password,
use plain dm-crypt, or LUKS without management features (i.e.
do not change the password). If you cannot protect the password,
do not use an SSD. Or use LUKS with the header detached and 
stored in a raw partition on a conventional HDD (via the 
--header option).

Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno at wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
One of the painful things about our time is that those who feel certainty 
are stupid, and those with any imagination and understanding are filled 
with doubt and indecision. -- Bertrand Russell 

More information about the dm-crypt mailing list