On 11.12.2013 20:16, Heinz Diehl wrote: > On 11.12.2013, tada wrote: > > > I was wondering if it is possible to add something like shred or wipe > > functionality for Luks devices, call it luksWipe, to safely delete the > > luks header > > You can do that easily by running dd against the first MB's of the > respective partition.. > > dd if=/dev/zero of=/dev/sdaX That heavily depends on who is the "bad guy" and what storage technology is used. For a non-hybrid HDD a single pass is suppossed to be enough to permanently overwrite anything there was before, no recourse whatsoever. (Or only the millions of dollar range, a.k.a. "State sponsored enemys") Non-rotating-platters-of-rust, namely NAND-Flash, are much trickier. If you only need to defend against an attacker investing a handfull of dollars (a.k.a, let's connect the thing and see what we get with standard "get me block X"-commands) a single overwrite/TRIM/Secure Erase is enough. But with just slightly more money (a.k.a., let's desolder the chips and see what's the raw contents) it's gets tricky pretty fast. Like you have to overwrite the (whole(?!)) contents with random data several times and you would still not have a 100% guranteed that the original content is really overwritten and not sitting somewhere as "spare" waiting to be reused. Altough at least some current SSD (don't know which ones) are supposed to be secure if you use Secure Erase. Thoses SSDs always encrypt the content as a way to guaranteed randomness of the data, which is supposed to be better for the flash-cells. So when you need a "scrambler" anyway, you just use AES256 and also have something you can advertise, 2 flies 1 stone. So when you secure erase such a SSD it (supposedly) discards the previous encryption key and generates a new one. If that is implemented correctly (which you or i can't really proven one way or the other) it would be safe. A single Secure Erase (overwriting not necessary) effectivly would make the problem "you need to brute force an AES256 key" to even get to the RAW content. -- Matthias _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
