Re: Default number of overwrites in shred

[Peter Eckersley]

On Thu, 2007-05-03 at 19:56 +0100, Philip Rowlands wrote:
> On Wed, 2 May 2007, Peter Eckersley wrote:

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

I think the disk density effect is a ratchet that's greatly in our
favour.  I think it's just a question of how we distribute the benefit
of the ratchet between security and convenience.

> Why 5 passes, and not 3 or 7?

Any of these would be fine by me :)

I don't have proof that nobody could ever read something that had been
scrubbed 3 times, but once one has factored in the observation that
security is <= the weakest link, I really doubt that this will be a
serious problem in the real world.

On the other hand, people avoiding shred because it's too slow is a
serious problem :).

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

We're certainly working on making sure that userspace chattr()s the
attribute.  Apparently, for many journalling filesystems (ext3 and maybe
Reiser, IIRC), shred should still work pretty well as-is -- I guess
that's because the filesystem promises metadata consistency, not data
consistency.  For the others, we can certainly ping the developers about
it.  We could potentially work on patches too, but that's less likely
unless there's an obvious case where the patch would make a lot of
real-world difference.


-- 
Peter Eckersley                            address@hidden
Staff Technologist                Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993