Secure delete with python

[Boris Genc]

Hi everybody.
I was wandering is there a method or a function already implemented in
python that supports secure deletion of data?

I'm interested in something which is able to securely wipe data (from
single file to bunch of MB's), and that should run both on Linux and
Windows.

I tried on google, but I hadn't found anything useful to me.

Thank you very much in advance.

Boris Genc

[Roy Smith]

Boris Genc <boris.genc@REM OVE_mindless_ME .com> wrote:

Hi everybody.
I was wandering is there a method or a function already implemented in
python that supports secure deletion of data?

I'm interested in something which is able to securely wipe data (from
single file to bunch of MB's), and that should run both on Linux and
Windows.

When people talk about secure deletion of data, they generally mean
things like over-writing the physical disk blocks that used to hold the
file with random data. The details of how you do this is extremely
operating system dependent (and probably also on what kind of file
system, hardware, etc). Not to mention that the definition of "secure"
will vary with the type of data, and who's doing it (i.e. what I
consider secure probably doesn't pass muster with the military).

[Benjamin Niemann]

Boris Genc wrote:

Hi everybody.
I was wandering is there a method or a function already implemented in
python that supports secure deletion of data?

I'm interested in something which is able to securely wipe data (from
single file to bunch of MB's), and that should run both on Linux and
Windows.

I tried on google, but I hadn't found anything useful to me.

Thank you very much in advance.

Boris Genc

something like

fp = open(path, "wb")
for i in range(os.path.g etsize(path)):
fp.write("*")
fp.close()
os.unlink(path)

is probably all you can do in a portable way (multiple write phases with
different data could improve the 'security'). But a problem that cannot be
solved in a portable way is that the data might exist at other locations on the
disk (e.g. temporary file, backup, swapfile...). Unless you know *exactly* that
there *cannot* be another copy of the data, you would have to erase all unused
parts of the filesystem, too - a process that heavily depends on which
filesystem is used.

[Benjamin Niemann]

Benjamin Niemann wrote:

Boris Genc wrote:

Hi everybody.
I was wandering is there a method or a function already implemented in
python that supports secure deletion of data?

I'm interested in something which is able to securely wipe data (from
single file to bunch of MB's), and that should run both on Linux and
Windows.

I tried on google, but I hadn't found anything useful to me.

Thank you very much in advance.

Boris Genc

something like

fp = open(path, "wb")
for i in range(os.path.g etsize(path)):
fp.write("*")
fp.close()
os.unlink(path)

and there is no guarantee that this actually overwrites the old file. The
filesystem may choose to write the new content at another location of the disk,
leaving the original data untouched.

[Boris Genc]

On Mon, 06 Sep 2004 09:10:49 -0400, Roy Smith wrote:

When people talk about secure deletion of data, they generally mean
things like over-writing the physical disk blocks that used to hold the
file with random data. The details of how you do this is extremely
operating system dependent (and probably also on what kind of file
system, hardware, etc). Not to mention that the definition of "secure"
will vary with the type of data, and who's doing it (i.e. what I
consider secure probably doesn't pass muster with the military).

Yes, I was thinking about overwriting the data I want to be deleted with
random data. I know that things like that are OS specific. I wasn't
thinking about all those Gutmann methods and 27 passes, it's more like a
simple utility, more "hide from your sister" than "hide from the
government" type:)

Anyway, thank you guys. Benjamin, I think your method will suit me, thank
you.

[Paul Rubin]

Boris Genc <boris.genc@REM OVE_mindless_ME .com> writes:

I'm interested in something which is able to securely wipe data (from
single file to bunch of MB's), and that should run both on Linux and
Windows.

I wrote something like that:

http://www.nightsong.com/phr/crypto/keytree.py

Explanation at: http://tinyurl.com/67beu

[Ville Vainio]

>>>>> "Benjamin" == Benjamin Niemann <b.*******@bett ernet.de> writes:

fp = open(path, "wb")
for i in range(os.path.g etsize(path)):
fp.write("*")
fp.close()
os.unlink(path)

Benjamin> and there is no guarantee that this actually overwrites
Benjamin> the old file. The filesystem may choose to write the new
Benjamin> content at another location of the disk, leaving the
Benjamin> original data untouched.

Seriously? What OSen are known for doing this? I'd had thought that if
the file size is unchanged, the data is always written over the old
data...

Also, when overwriting a file, it's better to do it several times,
with alternating bit patterns and "syncing" the disk after each
pass. Of course even that is not going to guarantee anything because
it may just go to the hardware cache in the disk unit, but it's
reasonable if you are overwriting lots of data at once.

Performing these steps, you'll at least get a good false sense of
security ;-).

--
Ville Vainio http://tinyurl.com/2prnb

[Dennis Lee Bieber]

On Mon, 06 Sep 2004 15:25:51 +0200, Benjamin Niemann
<b.*******@bett ernet.de> declaimed the following in comp.lang.pytho n:

fp = open(path, "wb")
Opening for "w", on many systems I've used, basically creates a
new file that may or may not use the same disk region (it definitely
wouldn't on UCSD P-system -- when I used that all files opened for
output were opened in the largest contiguous space on the disk).

Opening the file for "r+" is probably better; since it indicates
one may wish to read from the file along with writing to it, then the
original file must be available -- and I've not heard of any OS that
makes complete copies of a file during updates (I'm not counting the
behavior of editors/word-processors that read the entire file into
memory and create a temporary backup copy).

-- =============== =============== =============== =============== == <
wl*****@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
=============== =============== =============== =============== == <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.ne tcom.com/> <

[Andrew Dalke]

Ville Vainio wrote:

Seriously? What OSen are known for [writing new content at
another location of the disk]? I'd had thought that if
the file size is unchanged, the data is always written over the old
data...

It can even be filesystem specific. Back in the days
of WORM drives (do people still use those?) you could write
once to a place on the drive, but read it many times.
(Write Once Read Many). Changing a file meant writing a
new copy of it and writing a new index to point to the
new file, ignoring the old. That is, all copies of the
file would stay on the disk.
The VMS systems always kept an old copy of the file around
unless you explicitly deleted it. By default a directory
listing would only show the most recent copy of the file,
but you could tell it to show all the versions, which
would look like (roughly, been 15 years since I last saw VMS)
MYFILE;1
MYFILE;2
..
MYFILE;94

It was believed this feature was a deliberate ploy of
DEC to sell more hard drives. ;)
If you read a file then wait a while, and during that time
the OS decided to defragment the drive then the location
of the file could easily be changed from underneath you.
Andrew
da***@dalkescie ntific.com

[Roel Schroeven]

Ville Vainio wrote:

>>"Benjamin " == Benjamin Niemann <b.*******@bett ernet.de> writes:
>> fp = open(path, "wb")
>> for i in range(os.path.g etsize(path)):
>> fp.write("*")
>> fp.close()
>> os.unlink(path)

Benjamin> and there is no guarantee that this actually overwrites
Benjamin> the old file. The filesystem may choose to write the new
Benjamin> content at another location of the disk, leaving the
Benjamin> original data untouched.

Seriously? What OSen are known for doing this? I'd had thought that if
the file size is unchanged, the data is always written over the old
data...

VMS, I believe, has a versioning system built into the file system. Each
time a file is saved, a new version is created while the old versions
are still there. All from hearsay though, I have never used or seen VMS
myself.

--
"Codito ergo sum"
Roel Schroeven