Add randomising into that loop and you should be safer. As long as you
realize (which it appears you do) that this isn't 100% safe.

It is.  You have no guarantee that the new copy of the file is being
written back to exactly the same physical sectors on disk that the
original file came from.  Also, as Lasse said, you need to write a
different random byte array at each repetition.

You really need to be working at the level of physical disk sectors -
find out what sectors this file occupies, overwrite specifically those
sectors and then delete the file normally.

One possible solution might be to install a third party disk
wipe/shredder utility on every laptop and use your C# program to start
it remotely.  That way you do not have to do the heavy lifting of the
actual erasing, you just have to set the utility up correctly and
point it at the right file.  Pick a shredder with a command line
interface, or equivalent, so you can easily start it programatically.

rossum

Check out this whitepaper's section on secure deletion (pg 7):
http://www.sans.org/reading_room/whitepapers/incident/631.php

It should give you an idea of what "secure" really means, as well as a summary
of the DoD 5220.22M spec on what the government considers the minimum steps to
sanitize the data.

It also discusses the other issues that have been brought up in this thread
throughout the rest of the paper.

Keep also in mind that a a dedicated cracker may have the resources necessary to
counteract your methods. This is why one of the DoD options for purging data is
incinerating the drives. That said, that initial step you mention -- defeating
undelete software/requiring a cracker with access to proper equipment -- is
certainly achievable.

Chris.

Everything that "rossum" writes is correct AFAIK.  However, it's not clear  
to me that it's actually something to worry about.

You've written that you are not in need of a truly high-security solution,  
but rather simply want to protect against simple "undelete" attempts.

It's correct that when you write to the file from the file API level, you  
have no true guarantees about whether the file stays in the same place on  
the disk.  However, assuming that the file length doesn't change, you've  
locked the file (i.e. opened it in non-shared mode) so that no other  
process can delete or otherwise change it, it would be a very odd file  
system implementation that would move the file on you while you're simply  
overwriting existing data.

Also, while it's true that the same data could exist elsewhere on the  
disk, there's not really any practical way to deal with that after the  
fact, except by wiping the whole disk.  If that's a concern, you really  
need to impose security on how the data's managed while it's being used,  
rather than trying to somehow delete it later.

As far as the basic "prevent undelete" issue goes: you definitely don't  
need to read the existing file into a byte array.  That's silly: you're  
not going to use that data, so why read it in?  You can use the FileStream  
class to open an existing file without changing its length, and then write  
zeroes to the file, at least a few K at time (for performance).

This should address the "undelete" scenario just fine.  It won't do  
anything to prevent deeper analysis that involves recovering the data from  
the disk media directly as noted elsewhere, but you haven't written  
anything that suggests to me that's a requirement.  Writing zeroes is  
sufficient for blocking access to anything that goes through the regular  
OS file system management.

If you did want to block deeper analysis, you could write randomized data  
instead of zeroes, many times...I forget the exact levels of security, but  
my recollection is that 7-8 times is considered adequate for low-security  
data, and 30-40 times for high-security data.  For true high-security  
compliance, you really do need to operate at the disk sector level rather  
than the file level to make sure you're actually overwriting the original  
data rather than writing new data elsewhere.  But in truth, as long as  
you're not modifying the length of the file, NTFS and similar file systems  
are not, I think, going to reallocate the file layout on the disk while  
you're writing to the file.

Note that all of the above assumes you're writing a remotely-accessed  
utility that itself operates on the disk locally.  I still think it's  
unlikely that a file accessed across the network would move its physical  
location on the disk while you're writing to it, but introducing the  
network always adds more uncertainty as to the correlation between what  
the application is doing at the file level and what's really going on with  
respect to the physical media.  I wouldn't depend on an over-the-network  
implementation even for low-security needs.

Pete