Re: Wipe2fs - utility to wipe unused space in ext2/3
From: /dev/rob0 (rob0_at_gmx.co.uk)
Date: Wed, 20 Aug 2003 09:39:35 -0700
In article <firstname.lastname@example.org>, Chuan-kai Lin wrote:
> I discovered a surprising fact: that under normal conditions no data is
> actually left in the slack space after the end of files!
> all the previous data in in slack space is overwritten. It is more work
> for the kernel to preserve the data in the slack space, so the kernel
> generally does not bother with these things. In the case of recent
> Linux kernels, the slack space is overwritten by 0.
So, it still can be worthwhile to use some random overwrites.
>> And in so doing, one should become aware of the need for entropy and of
>> the limitations of pseudo-random number generators (PRNG's). In theory
>> at least, if a PRNG lacks entropy, its output could be predicted, and
>> you might as well have used /dev/zero and /dev/ff.
> I never quite understood this: suppose I overwrite the entire disk with
> random numbers 4 times to wipe the original data on the disk. How would
> knowing the random numbers used help physical media-based recovery?
IIUC: if the pattern can be recreated it will greatly ease the process
of physical examination of the madia.
Oh, and a minor point: the use of the word "recovery" in this context is
inaccurate, a "pet peeve" (annoyance) to me. If I write data to my
media, it belongs to me. If I determine that no one should have access
to it, and then wipe it, "recovery" is in fact "theft".
Yes, in some cases, such as if the media belongs to a company I worked
for, it is true recovery. But I do not recognise the right of
governments to access private data, no matter the circumstances. I *do*
recognise their power to do anything they want, and that the majority of
the people in this world probably do not agree with me. I'm not wishing
to trigger a flame war, but I think it's useful to cut through statist
-- /dev/rob0 - preferred_email=i$((28*28+28))@softhome.net or put "not-spam" or "/dev/rob0" in Subject header to reply