Re: Default number of overwrites in shred

[Paul Eggert]

Jim Meyering <address@hidden> 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!  :-)