Jim Meyering <[EMAIL PROTECTED]> writes: > I too would feel better with a minimum of 2 or 3 passes, just in case.
If we want to be conservative, then the U.S. Defense Security Service's Clearing and Sanitization Matrix (2005-06-27) <http://www.dss.mil/isp/odaa/documents/clearing_and_sanitization_matrix.pdf> specifies the following methods for rigid disk: * For clearing, "Overwrite all addressable locations with a single character." * For sanitization, "Overwrite all addressable locations with a character, then its complement. Verify 'complement' character was written successfully to all addressable locations, then overwrite all addressable locations with random characters; or verify third overwrite of random characters. Overwrite utility must write/read to 'growth' defect list/sectors or disk must be mapped before initial classified use and remapped before sanitization." Oh, and big print above it, "THIS METHOD NOT APPROVED FOR SANITIZING MEDIA THAT CONTAINS TOP SECRET INFORMATION." (Just thought you'd like to know: the DoD requires degaussing or destruction instead, for top-secret disks. Also, shredding does not count as destruction: you have to disintegrate, incinerate, pulverize, or melt) Anyway, 'shred' currently does the first, but not the second, as it doesn't verify what it's written. That should get fixed, no? How about this idea, to get 'shred' to conform to DoD 5220 rules for sanitization for classified (but not top secret) disks? Change the default number of passes to 4. If the number of passes is 4 or more, then use these three passes first: * Write all 1s. * Write all 0s. * Verify that all 0s were written. After that, do N - 3 passes the way that 'shred' already does them (except omit the all-1s and all-0s passes). This would suffice for sanitization. Pass 3 requires read access to the file, which 'shred' currently doesn't do. I suggest that we require read access to the file; I have some qualms about shredding something I can't see. > Although a program like shred cannot choose how far from a track to write > its data, I have to wonder if one effect of its current 25-iteration > approach is to write with slightly different offsets. Could be, but I doubt whether it helps much these days. By the way, for floppies, mag tape, and bernoullis, none of this stuff is approved by the DoD. You have to degauss or destroy. I looked into the ATA side a bit more. The hdparm command has --security-erase and --security-erase-enhanced options that look like they should use the ATA functions in question. This could well be more suitable for the paranoid than 'shred' is. However, for these features the current hdparm manual says "THIS FEATURE IS EXPERIMENTAL AND NOT WELL TESTED. USE AT YOUR OWN RISK." So perhaps 'shred' should wait a bit before using this kind of facility, even if it's faster and more-secure. In the meantime, perhaps the EFF would like to test hdparm? (On their own drives, not mine! :-) _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
