On Fri, Aug 10, 2012 at 05:49:49PM +0200, antispam06@xxxxxxx 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 protection. 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 correctly. 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 on LUKS_STRIPES is. 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 -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
