On 1/3/08, new_guy <[EMAIL PROTECTED]> wrote: > I'm working on putting a website up now where I'll fully disclose the > details. Lots of pictures and details. I will attribute the dd used to > OpenBSD (the best OS on the planet bar none... although the dd on the > install CD did not support the conv option... I would have liked to have > done conv=noerror,sync). I plan to ship the drive off tomorrow. I plan to > put this myth to rest... where it belongs.
you are not proving that data cannot be recovered. you are proving that it cannot be recovered at a cost of $100. if you have not spent $1 million, you cannot claim that someone with $1 million cannot recover the data. that's just how things work. but this has, as ever when it comes up, gone terribly far astray. the first rule of data recovery: in order for your data to be recovered, there has to be someone willing to do (pay for) the recovery. the original question was about overwriting a file in such a manner that the drive could still be used. melting or shredding the drive does not result in a usable drive. if i never see another chucklehead recommending "use thermite" it will be too soon. overwriting the disk with /dev/zero or any other pattern does result in a usable drive, but not a usable filesystem. so now we're down to just scorched earth, but we won't salt the fields. again, not helping. so we come back to rm -P. this comes pretty damn close. it kills the targeted file with no collateral damage. it even does a reasonable job of overwriting more than once, though not with the "guttman superpattern", but that's a load of crap anyway. but there are three things rm -P does not delete. it doesn't delete any temporary files created when the original was being edited. it doesn't delete any blocks or fragments that ffs may have rearranged in a cluster op. it doesn't delete any bad blocks that the disk itself moved around. it also doesn't delete any data that's been posted on youtube, but that's a whole nother issue. the first is an application issue, but it can be very difficult to control. this even applies to the thermite people. if /tmp is on a different disk than /home, nuking one won't destroy all the data. you have basically no control over what ffs does. this also applies if you have ever truncated the file down. rm -P can only overwrite the current file. you can solve both these issues by writing a tool that overwrites all unused disk blocks. the code for fsck would be a good place to start writing such a tool. then you can run it periodically and know that whatever free space is on your filesystem is clean. as for the disk relocating blocks, there's nothing you can do programatically. by the same token, however, it's not so trivial to recover and it depends on your secret data having been relocated. for most people, doing a cost/benefit risk analysis here should come up somewhere short of vaporization. the solution nobody ever comes up with but which is so totally obvious is to prevent the data from being stored on the hard drive in the first place. holy cryptographic kryptonite batman. if you encrypt the data, you don't have to worry about somebody reading it even if you don't delete it at all. if you are giving away a hard drive and intend for the recipient to use it, wiping it is the best you can do. in most cases though, hard drives are cheap, so you're not likely to give away a disk without data. instead, you want to dispose of the disk and data, permanently. in that case, a quick whack with a hammer to a control chip and a connector and tossing into an anonymous dumpster is even faster than wiping.
