How Secure is Secure Empty trash?

J

JeffCGD

Registered
Exactly how secure is Secure Empty trash?
in the betas of 10.3, there was a pull down menu for secure empty trash showing 3 pass, 5 pass, and 10 pass over-writing. Lord knows what actually made it into the final release.

And how does this process compare to say, Norton Wipe Info? Better? Worse? Anyone have a frame of reference? Has anyone tried to test how effective Secure Empty trash is at destroying data you want gone?
 
Basically, imagine burning your harddrive in extreme temperatures... Okay, now try to recover the data. Pretty much impossible. That is the basic idea with the secure erase, however your Harddrive is not rendered useless after such an operation (as would be with extreme temps) :) So rest easy, and delete away.
 
I doubt that anything this side of a National Security Agency lab would be able to recover files that have been securely deleted. About the only method more secure is taking a bench grinder to the surface of the hard drive.
 
cybergoober said:
I believe the current scheme is 7 pass - which is Government-grade secure erase.
Click to expand...

It might even be an 8 pass because there is a option in the Disk Utility to write data on the disk 8 times when you reformat a drive, I wonder if it's the same idea....

(or i could just be a complete idiot)
 
Seriously guys, one-pass is good enough.

It's pretty darn hard to sense what was written on a disk, and once it's been overwritten, it's near impossible for any software-based app to recover a file, and you need to go to more extreme measures in a recovery lab.

If however you do have a reason to be worried (and everyone does :)) use this in the terminal:
rm -P <filename>
which :
Overwrite regular files before deleting them. Files are
overwritten three times, first with the byte pattern 0xff,
then 0x00, and then 0xff again, before they are deleted.
Click to expand...

Or even install srm (secure rm) from Fink if you like, which has a few more options.

HyperLite, good logic, I'll go and check AKB...

EDIT: AKB doesn't seem to have much detailed info on how many times SET overwrites data. And also, it seems that srm is bundled with Panther, no need to Fink! http://www.macosxhints.com/article.php?story=20031025092806502
 
michaelsanford said:
Seriously guys, one-pass is good enough.

It's pretty darn hard to sense what was written on a disk, and once it's been overwritten, it's near impossible for any software-based app to recover a file, and you need to go to more extreme measures in a recovery lab.

Or even install srm (secure rm) from Fink if you like, which has a few more options.
Click to expand...

Mac OSX uses srm in the Secure Empty Trash procedure currently; I've seen it running in the terminal/Activity monitor when I use Secure Empty Trash.
 
Hey that gives me an idea.

A few minutes later : I had a look through some preferences files to see if there was an option to pass through the number of passes to `srm` but there isn't one I could find.

The default for `srm` is 35 pass Gutman method, which is pretty darn secure, so we can assume that it uses that method for Secure Empty Trash.

That answer your question ?
 
Well, I'll agree that the Secure Empty Trash method of the Finder uses srm, but I don't know if we can be 100% sure it uses the default options of srm. Unless someone can dig up the code or .plist entry or something in the Finder that specifies which flags the Finder uses for srm, we won't really know. :(
 
The problem with any secure deletion utility, is they only erase the parts of the HD that the file occupies now. The file might have moved all over the drive in the past.

For example, if you defragment the disk (which OS X does on the fly, without you needing to tell it), the file will move to a different part of the disk. Then you run srm or similar on it, and it erases the new location 35 times with random data, but the old sectors it used to occupy are left alone.

The only way I can think of to deal with this (maybe someone else can come up with a better way) is to write a bunch of data to the disk, and let the entire drive fill up completely. For example, you could
cat /dev/urandom > foo
Then you would securely delete this file, that has just occupied nearly all the empty space on your disk.

That still doesn't catch it all - if the file you're shredding has been defragged, and some other file ended up occupying a block that used to hold the file, before you get around to shredding all the slack space on the disk, then that block is spared the 35 rounds of Gutman goodness.

Really, the only way to make sure that any disk block that ever held your file would be to
srm /dev/disk1
or whatever disk held the file you want to eliminate. Course, that'll eliminate everything else on the disk...
 
You must log in or register to reply here.
Back
Top