Thank you all for your detailed answering, I appreciate it. It seems I have some misunderstandings regarding how SSDs work internally. Will do further reading :) By the way my question was more of an 'academic' nature, I'm aware I certainly don't need that level of security, I was just thinking about it after reading a lot about it. > > report all zeros for TRIMed sectors. Either way, the flash chips > > will contain all random data ... > > No, they won't. They will all be cleared. Of course... now I read about it, it's clear to me. For my setup, I will just do an ATA secure erase before using the drive. Thanks again, Merlin On Wed, 8 Nov 2017 18:34:38 -0600 Robert Nichols <rnicholsNOSPAM@xxxxxxxxxxx> wrote: > On 11/08/2017 11:36 AM, Merlin Büge wrote: > > Hello all, > > > > > > I want to use an SSD (Samsung 850 PRO 512GB) for a fully encrypted > > Linux system. I've read the cryptsetup FAQ and various posts in the > > internet and I'm familiar with the common problems/pitfalls > > regarding dm-crypt on SSDs. > > > > To avoid information leakage about the storage device's usage > > patterns, it is generally recommended to fill the entire device > > with random data before setting up encryption. It is also > > recommended to issue an 'ATA secure erase' to SSDs before using it > > to avoid performance issues. > > > > But doing these two things, either my (1) random data gets > > 'deleted' via the (2) 'ATA secure erase' (the SSD will report all > > zeros), or I end up with degraded performance when (1) issuing 'ATA > > secure erase' before > > (2) putting random data on it. > > > > I thought of TRIMing the SSD via 'blkdiscard' instead of using > > 'ATA secure erase' after putting random data on it (twice, see [0]), > > but that should make no difference, since the SSD will most probably > > report all zeros for TRIMed sectors. Either way, the flash chips > > will contain all random data ... > > No, they won't. They will all be cleared. The whole point of TRIM or > blkdiscard is to allow the controller to clear the blocks of flash > cells so that they will be immediately available for writing when > needed. Writing random data to the flash cells and then immediately > clearing them is fairly pointless. All it does is mask any residue a > cleared cell might have of the last data it contained. People who > need that level of security don't ask about it here. > > -- > Bob Nichols "NOSPAM" is really part of my email address. > Do NOT delete it. > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Merlin Büge <toni@xxxxxxxxxxxx> _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
