Re: Default number of overwrites in shred

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> 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?

I agree.

> 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.

Yes.  Same here.
I like your plan.