Re: Secure delete ie shred a file

[cyclist38]

i've done this before by first encrypting the file with a temporary key, write it back to disk, then delete the file. the file is still recoverable by commercial utilities, but not the information.

[tirwhan]

I'm not sure this is actually as secure as you think it is. You have no guarantee that your filesystem will use the same blocks for your new (encrypted) data as for the old, and even less guarantee that the device driver/device will map those blocks to the same physical sectors. Flash devices, for example, will try hard to use new, unallocated space, because the flash media has a very limited number of write cycles within its lifespan. So the information in the original file may no longer be accessible to the filesystem but it can still be read directly from the disk.

At the very least, you need to make sure that your encrypted/zeroed file is the same size as or larger than your original, otherwise some of your original data can remain in the slack space between file and block size.

Secure file deletion depends on several variables, including the file system and the physical device used. The only general way to do this semi-securely is GrandFather's suggestion of deleting the file and filling the then empty space on the partition with data multiple times (making sure you flush your page cache between passes). Even then there can be problems, like for example NTFS's alternate streams.

Personally I'd probably go a different way and rather transparently encrypt the file while using it. If all you're guarding against is later recoverability you just need to make sure the encryption key cannot be recovered, and even if you fail that it is very probable that simple corruption of your encrypted file (e.g. by managing to wipe it partially) will render the file completely unrecoverable.

[fluffyvoidwarrior]

So won't a sequence like this actually write to the same disk sectors (ntfs hard drive)
step1 - set file pointer position,
step2 - sysread lump of data,
step3 - encrypt lump of data,
step4 - reset pointer to original posn,
step5 - syswrite lump of data in same file posn,

or is it just a case of probably , sometimes.

[tirwhan]

Probably, sometimes :-). Without information on how the file system, device driver and device firmware allocate space at that particular point in time you have no way of knowing. sysread is too far removed from the actual disk operation to make a guarantee on how one impacts the other. In general this may work, however, there are some cases where it definitely won't (e.g. Flash drive, different sized data, remapped bad sectors/clusters) and AFAIK the behaviour in other cases is undefined.

[emazep]

i've done this before by first encrypting the file with a temporary key

Why encrypting the file?!
Overwriting the file with random bytes is security-wise the same (or it's even better, since there is no chance that someone could decrypt the file content).
And using random bytes is much, much faster and memory efficient than an encryption.

Update

And overwriting the file with a fixed pattern would be even better! ;-)

Ciao,
Emanuele.

[cyclist38]

nice point actually - never thought about using random bytes. ++

[fluffyvoidwarrior]

I think that will do the job nicely. p.s. Wish I'd thought of that