Wiping Out Data

[Jeffrey F. Bloss]

Peter Garrett wrote:

> On Tue, 27 Mar 2007 14:17:45 -0400
> "Jeffrey F. Bloss" <jbloss at tampabay.rr.com> wrote:
> 
> > It should also be noted that utilities like shred and dd can be utterly
> > useless on file systems like ext3 because data is "cached" rather than
> > committed to disk after every write operation. IOW, you could overwrite
> > bits randomly 100 times, but it all happens in "RAM" so when the
> > housekeeping is done you've only *physically* overwritten the bits once,
> > with the last pattern your software used. Typically this is straight
> > zeros, so you've really spent a lot of time accomplishing nothing much
> > at all. :(
> 
> Interesting. Would it help/ make a difference to run " sync" after each
> iteration ?
> 
> just curious...

Maybe on a hard drive or similar media, but you'd have to run a loop of
a single iteration of shred and a sync, repeated X number of times to as
effective as X overwrites by shred itself run normally. Even then,
there may be something about the way shred's random number generator
is initialized that makes multiple calls less random than one "seed"
with multiple iterations. That's a matter for hard core
mathematicians. ;)

In my humble opinion using dd this way would be preferable, assuming
that's not what shred itself does in effect but without the
interspersed sync calls. Then I'd have to say "either way".

I'm also less than confident that a sync call physically writes every
bit of data to a drive. I know it's suppose to flush buffers and all,
but there may be things outside its scope that still "cache" data. In
fact my own very unscientific experiments a while back with a USB flash
drive and my own shred/sync script left me convinced sync isn't as
thorough as it could be. After large transfers and a sync, "ejecting"
the drive often still seemed to cause data to be written to the drive.
According to the flashing dialog and the drive's lights anyway. ;)

Of course that's just a casual operation that might have been the
result of numerous irrelevant things, but if I were trusting my life
and limb to a file wiping scheme they're questions I'd certainly want
answered. One *might* be able to do that by crafting a special
application that wrote preset patterns over some data, running it with
sync and without, and rather than "ejecting" a device just brutally
unplugging it or powering it down. Then comparing those two results on
a bit by bit basis with the same controlled overwrite of the same
device ejected "normally". If there's any flaws in sync they should
show up pretty quick.

In any case, I think the bottom line is that we really shouldn't trust
this sort of "live" file wiping for anything but casual use. If you
need any sort of real security boot from some other media and wipe the
entire drive in an environment where side effects are less of an issue,
using tools that couldn't give one nit about what file system they're
mutilating.

Or better yet, employ strong encryption for sensitive data and make the
whole issue of whether or not someone might recover after a wipe
totally irrelevant. ;)

-- 
     _?_      Outside of a dog, a book is a man's best friend.
    (o o)         Inside of a dog, it's too dark to read.
-oOO-(_)--OOo------------------------------[ Groucho Marx ]---
                    http://wrench.homelinux.net/~jeff/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 892 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20070327/bdb75472/attachment.sig>