Brian Lavender wrote: > On Wed, Sep 09, 2009 at 09:20:30PM -0700, Bill Broadley wrote: >> Short answer, one wipe is enough (At least for NIST, and one of the British >> Infosec standards), wipes miss bad sectors, the ATA secure erase command is >> worth checking out. > [snip] > I think caching is a concern on some systems, so more wipes seems to > magically make the write go to the actual media. But I would agree with
I don't see how. After all a system wouldn't work well without reliable writes. Sure you should do a sync and order shutdown and not pull the power the second the dd command comes back. Especially if the disk light is showing activity. NIST seems to have made a very informed decision on the single write is enough. Keep in mind even if linux random dropped writes without telling anyone the cache is much much smaller than the disk on any sane system. > one wipe is probably enough. I had not thought about bad blocks. Secure erase or destruction is the only way to get those. >> So if you don't use secure wipe and won't lose sleep at night over a few bad >> blocks being potentially recovered I'd recommend something like: >> >> dd if=/dev/urandom of=/dev/sd<whichever disk> > > Your computer must have a lot of entropy! Note that that device gathers Note the above is /dev/urandom, only /dev/random is limited by entropy. Indeed a read of a disk worth from /dev/random would take a very long time. As long as your attacker doesn't have root access to the machine doing the wipe during the wipe you should be good. Pretty much all linux distributions since 2000 or so save the seed state across reboots. >From the random man page: If a seed file is saved across reboots as recommended above (all major Linux distributions have done this since 2000 at least), the output is cryptographically secure against attackers without local root access as soon as it is reloaded in the boot sequence, > entropy from the system. When an event happens, it may be worth one or > two bits. Last time I wrote a program that read from that device, it > seemed that I got a number of bytes, and then I had to wait as various > events occured to the system. That is why they often tell you to move the > mouse around when generating keys. It generates entropy for the system. Yes, /dev/random blocks when there isn't enough entropy, thus /dev/urandom above. > You can feed that data from /dev/urandom into AES as the key, then > use Cipher Block Chaining so that it looks more random. Essentially, Seems a bit silly, /dev/urandom does this already for you. If interested you might like RFC 1750 "Randomness Recommendations for Security". > you are using the /dev/urandom as the key to produce cipher text. > I believe dban does this. Seems a bit silly. So if you use /dev/urandom for the key for AES, what do you actually encrypt? > If you wipe with /dev/zero, then the adversary could be correct for > half the bits assuming that they are equaly distributed! Er, right. How is that a problem? Say I buy a new disk full of zeros, it has likely around half the bits identical to your disk. The trick is I don't know which ones. Sure for each bit I have a 50% chance. But even guessing 64 in a row is 1/2^64 or so which makes it rather unlikely. Kinda reminds me of printing out all the ssn numbers and then saying I have you SS number in that list... I've violated your privacy... then again I don't know which one it is. Basically with todays drive technology what you write is what you get, the "track edges" are gone, there exists no practical way to reads the bits from previous reads. I just picked /dev/urandom becuase it's cheap, easy to compute, er, oops. Looks like it would be faster to write all zeros then all ones. At least the 2 faster machines I have access to only manage 7.5MB/sec, any disk from the last few years should manage 40-50MB/sec and if it's from the last year or so likely double that or more. So what would be faster and more protective (but not as much as a secure erase) could be any two patterns. 0 then 1, of if you prefer any byte then it's compliment. _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
