I'm a bit late to the party, I know. But I just wanted to point out that NIST now requires only the regular 'secure erase' ATA command to sanitize a drive for anything that wouldn't require the drive to be pitched into a metal shredder, pulverised, ground into powder, and then melted into slag.
In other words, on modern hard drives, a single write with zeros is probably enough. And if it isn't, the data shouldn't have been unencrypted on the drive in the first place. I'm opposed to adding more complication to this utility. I'd prefer that it does it quickly and correctly, so that I will use it. The people who want 35 overwrites won't trust the tool we provide anyways. P.S. An advantage of writing with zeros is that it's easy to verify that the overwrite was done correctly. arc4random()... not so much. On Wed, Jul 25, 2012 at 10:01:13AM -0500, Todd T. Fries wrote: > Penned by Christian Weisgerber on 20120725 9:37.07, we have: > | Ted Unangst <t...@tedunangst.com> wrote: > | > | > So I'm wiping a file from a fairly slow USB stick and it's taking > | > forever. I don't really give a shit about some guy with a quantum > | > tachyon microscope taking it apart, > | > | But if you do, overwriting with a constant pattern is stupid. You > | want to overwrite the old data with random bytes, effectively running > | a stream cipher on any remnant signal. > | > | (And forget about this with flash media, where you each write to > | the same logical block may end up in different physical blocks.) > | > | > I just want the files to be gone > | > enough that a simple undelete tool won't bring them back. The three > | > wipes is the charm approach of rm -P is a little heavy handed. > | > > | > What I propose is making -P wipe the file once each time it's > | > provided. I get the simple whack the data for good option I want, the > | > paranoid weirdos get the rm `jot -b -P 4096` scrubber they want. > | > | Replace the memset() in pass() with arc4random_buf() and I'm starting > | to like it. > > There is a paper entitled "Secure Deletion of Data from Magnetic and > Solid-State Memory" > from the Sixth (6th) Annual USENiX Security Symposium that talks about this. > > For the extreme bit twiddling bunch, the recommendation is to use 35 rounds. > 1-4 using /dev/arandom > 5-31 using Guttman's deterministic patterns > 32-35 using /dev/arandom again > > I've seen diffs proposed to do this in 'rm' before introduce another flag. > > I could easily see how we could do parts of the above until 35 -P's are given. > > Also, consider the ramdisks, and make -P become something that is not compiled > `#ifdef SMALL'. > > One could, alternately, provide a 'secrm' alias to call some other tool to do > the bit wiping and finally call rm. > > I won't complain what happens either way, but I would be rather pleased if > something > of the Guttman's recommondations could be incorporated for high counts of -P.
