[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Default number of overwrites in shred
From: |
Philip Rowlands |
Subject: |
Re: Default number of overwrites in shred |
Date: |
Thu, 3 May 2007 19:56:30 +0100 (BST) |
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