Hi, I carefully read that page http://asalor.blogspot.fr/2011/08/trim-dm-crypt-problems.html to understand the basics behind the main security problem involved by trim commands. Simple ideas came to my mind, but I need to submit them to know how they fail (or by any chance how they may succeed). >From what I understand, TRIM commands are used to say to the SSD controller: "these sectors are discarded, so you can erase them at any time chosen by you rather than waiting an explicit rewrite from me". So, from a crytographic point of view, using TRIM commands is like replacing deleted files by "zero" files in a totally uncontrolled manner. This breaks the main purpose of cryptography: hiding as much things as possible. After TRIM commands, the SSD controller erases blocks whenever he wants after receiving the command. Thus, it seems to not inform us back where those blocks are remapped in its LBA translation table (not sure about that). So, what about running TRIM commands only in certain cases: on-demand / by sectors / ... ? The overall purpose being: - to limit the TRIMed space on device - to control the TRIMed pattern (spread it randomly as much as possible) Here the naive things: - send on-demand TRIM commands based on device write access rate and remaining free space - keep a table of TRIMed blocks or just their total size (send TRIM commands only below a certain size limit threshold) - send TRIM commands on randomly chosen deleted blocks only (not all deleted blocks) - write garbage to fill some TRIMed "blanks" (less than a threshold critical to ssd performance) - randomize device usage pattern when choosing blocks to TRIM (hide filesystem) Let me know if it could lead to real life solution. Any criticism appreciated. ~Alban. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
