Re: Default number of overwrites in shred

[Philip Rowlands]

On Wed, 2 May 2007, Peter Eckersley wrote:

> I was wondering if you would consider reducing the number of default 
> overwrites for "shred" from 25 to something more like 5?

The first question which comes to mind is "why 25"?

 From the first version which I can find:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=9a6aae1ed7c50466e23ceb721f88086061f35311
#define DEFAULT_PASSES 25       /* Default */

which references for its methodology
http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html

The Epilogue section is apposite here; in summary, a large number of 
passes is a redundant catch-all for different magnetic encoding 
techniques. A sensible change to make to shred might be to use only 
those passes relevant to current and near-current HDDs. The load spike 
referred to won't go away with a reduced number of passes, it would just 
be shorter-lived.

It's tricky to view security/performance tradeoffs to be anything but 
ratchet-like, only ever towards security. Perhaps it's even preferable 
to make --iterations be a mandatory argument, except for the breakage 
that would cause to old scripts.

Why 5 passes, and not 3 or 7?

BTW, are you also working to add solutions for journaled filesystems, 
such as the "s" (EXT2_SECRM_FL) attribute? (I have no knowledge that 
this is effective, but the API certainly exists.)


Cheers,
Phil