Secure delete with python

[Duncan Booth]

Re: Secure delete with python

Ville Vainio <ville@spammers .com> wrote in
news:du74qmb9mz s.fsf@amadeus.c c.tut.fi:
[color=blue]
> 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...[/color]

I don't know for certain, but I think it is a pretty safe bet that NTFS
allocates new disc blocks instead of updating the existing ones.

NTFS is a transaction based file system, i.e. it guarantees that any
particular disc operation either completes or doesn't, you can never get
file-system corruption due to a power loss part way through updating a
file. Transactions are written to two transaction logs (in case one is
corrupted on failure), and every few seconds the outstanding transactions
are committed. Once committed there is sufficient information in the
transaction log that even if power is lost the transaction can be
completed, and likewise any transaction that has not been committed has
sufficient information stored that it can be rolled back.

There isn't very much published information on the NTFS internals (any
useful references gratefully received), but so far as I can see writing
updates to a fresh disc block would be the only realistic way to implement
this (otherwise you would need to write the data three times: once to each
transaction log then again to the actual file). If the data is written
separately then the transaction log only needs to store the location of the
new data (so it can be wiped if the transaction is rolled back) and then
update pointers when it is committed.

The other reason why I'm sure overwriting an existing file must allocate
new disc blocks is that NTFS supports compression on files, so if you start
off with a compressed file containing essentially random data and overwrite
it with repeated data (e.g. nulls) it will occupy less disc space.

[Peter Otten]

Re: Secure delete with python

Paul Rubin wrote:
[color=blue]
> I think you're best off assuming that short of melting the platters,
> there's no way to ever erase data from a hard drive, i.e. that a
> sufficiently powerful attacker can recover every state that the drive
> has ever been in. The solution is to write only encrypted data to the[/color]

The german PC magazine c't has sent in hard disks overwritten once with
zeros to data recovery firms. No data was recovered. So unless your
opponent has secret service connections I'd say you are safe. He will
rather watch your screen or log your keystrokes than mess with the hd - if
he's not already in your WLAN that is.
[color=blue]
> has ever been in. The solution is to write only encrypted data to the
> drive, and don't store the key on the drive.[/color]

As a special case, avoid that the OS writes the key to disk while swapping.

Peter

[Neil Hodgson]

Re: Secure delete with python

For example source code and discussion for Windows see

http://www.sysinternals.com/ntw2k/source/sdelete.shtml

Neil

[John Lenton]

Re: Secure delete with python

On Tue, Sep 07, 2004 at 10:40:07AM +0200, Peter Otten wrote:[color=blue]
> [color=green]
> > has ever been in. The solution is to write only encrypted data to the
> > drive, and don't store the key on the drive.[/color]
>
> As a special case, avoid that the OS writes the key to disk while swapping.[/color]

or encrypt the swapfile. In fact, encrypt the disk, then partition it;
this is easily done with the device mapper in linux 2.6...

--
John Lenton (john@grulic.or g.ar) -- Random fortune:
Todo lo que nace es digno de morir. -- Goethe --

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBPbLdgPq u395ykGsRAmvIAJ 41SVhaTWAd3+8zV jANlFo0jCGWfgCg iqU/
cMQ+KqeulTq7QfL ypgZeC6g=
=Vz57
-----END PGP SIGNATURE-----

[Paul Rubin]

Re: Secure delete with python

"Neil Hodgson" <nhodgson@bigpo nd.net.au> writes:[color=blue]
> For example source code and discussion for Windows see
> http://www.sysinternals.com/ntw2k/source/sdelete.shtml[/color]

See also the stuff at briggsoft.com. Apparently a lot of so-called
secure deletion products on Windows don't work nearly as well as
claimed. Kent Briggs hangs out on sci.crypt and has evaluated a lot
of them besides marketing some of his own.

[Michael George Lerner]

Re: Secure delete with python

Andrew Dalke <adalke@mindspr ing.com> wrote:[color=blue]
> Ville Vainio wrote:[color=green]
>> 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...[/color][/color]
[color=blue]
> It can even be filesystem specific. Back in the days
> of WORM drives (do people still use those?)[/color]

I know that some government agencies were still using them as recently
as a couple of years ago .. there were some regulations that said that
you had to keep undeletable backups of everything. I think your choice
was basically between a warehouse full of file cabinets and a WORM
drive or two.

-michael

[Alex Martelli]

Re: Secure delete with python

Michael George Lerner <mlerner@NO.SPA MumichPLEASE.ed u> wrote:
[color=blue]
> Andrew Dalke <adalke@mindspr ing.com> wrote:[color=green]
> > Ville Vainio wrote:[color=darkred]
> >> 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...[/color][/color]
>[color=green]
> > It can even be filesystem specific. Back in the days
> > of WORM drives (do people still use those?)[/color]
>
> I know that some government agencies were still using them as recently
> as a couple of years ago .. there were some regulations that said that
> you had to keep undeletable backups of everything. I think your choice
> was basically between a warehouse full of file cabinets and a WORM
> drive or two.[/color]

....or much-cheaper CD-R (not -RW) disks...? Not sure about how well
they'll age, but they're write-once, read-many, too, and cheap (besides,
they don't cost much...;-).


Alex