12Jan2008 (UTC +8) On 1/12/08, Orlando Andico <[EMAIL PROTECTED]> wrote: > If you write all zero or all one to the disk, it's still technically > possible to get the data back. The original data "sticks up" or > "sticks down" out of the constant 1's or 0's. This also works with > erased audio tapes, it's possible to extract some or most of the > original audio from an erased tape.
True, it's technically possible to do so, but one of the tools you'd need is an electron tunneling microscope. So that puts most of us as S-O-L :) Trying to retrieve what was last printed on a laser printer, from its electron drum, is theoretically easier. > The US DoD has a standard for scrubbing, which is: > - overwrite with all 1's three times > - overwrite with all 0's three times > - overwrite with random three times Yup! To quote verbatim, the standard says to "Overwrite all locations with a random pattern, all locations with binary zeros, all locations with binary ones." And the methodology is for various types of PROMs. For HDD's (i.e. Rigid Disk), the Clearing and Sanitization Matrix only requires to either degauss it, or "Overwrite all addressable locations with a single character." The US standard is DoD 5220.22-M. > Although, in my opinion, a "strong" RNG is not needed. Even the cheap > pseudo-random number generator will probably be good enough, if speed > is what one's after. The main thing is to overwrite with a > non-constant pattern so that the original data is difficult to > extract. I agree with your opinion. Most of us do not have threats from organizations with massive computing resources, so /dev/urandom is good enough. /dev/random is stronger, but it just takes forever! /dev/urandom is becomes practical when you realize that you have project deadlines to meet, and a business to support. > On Jan 12, 2008 7:17 PM, Gerald Quimpo <[EMAIL PROTECTED]> wrote: ... > > which does the same thing. that runs in 45.509 s. So just > > reading from /dev/urandom costs you a lot of performance. why > > not just write zeroes to the disk? My bad, sorry. I had taken for granted the thought that everybody encrypts their HDDs, hence /dev/urandom and not /dev/zero. Anyway, if the HDD was over-written only with zeros, then you encrypt the HDD, one could see with a hex editor where the filesystem started, and then theoretically try to reverse-engineer the encryption algorithm. Remember, the bigger the fs, it's theoretically easier to decrypt it. However, if the HDD were initialized with random bits before installing an encrypted filesystem, then it's going to be a lot more challenging to decrypt the HDD, as the intelligence analyst (or attacker) can't easily tell when the encrypted fs started and ended. Drexx Laggui -- CISA, CISSP, CFE Associate, CCSI, CSA http://www.laggui.com ( Singapore / Manila / California ) Computer forensics; Penetration testing; QMS & ISMS developers; K-Transfer PGP fingerprint = 6E62 A089 E3EA 1B93 BFB4 8363 FFEC 3976 FF31 8A4E _________________________________________________ Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Read the Guidelines: http://linux.org.ph/lists Searchable Archives: http://archives.free.net.ph
