Erase unused space in a short amount of time.

[cyberjackal]

I know for the fact that wiping a large unused space may take a long time, especially if you use 3-pass or more. However, I remember reading a thread on another forum (or maybe it was on this forum) which suggests you can get around it by filling your hard drives with large duplicate files until the volume of free space becomes low enough to make it more suitable for wiping procedure. That way, the decreased free space would dramatically reduce the amount of time the erasing process would have take. In fact, I already did it by filling my hard drive with several large files. I now have only about 1.55 GB of free space left, but before I proceed with the "Erase Unused Space" task, I would need to seek your approval. Do you think it's a good idea to go ahead with this suggested procedure? Thanks.

By the way, here's my computer specs:

Compaq (model 7550)
Win XP SP2
2.4 Ghz Pentium IV
512 MB RAM
60 GB Hard drive (Seagate model)

 

[Joel]

By copying files you are doing the same thing as doing a pseudorandom 1-pass, before completing the procedure with your regular higher-security erase passes.

From a security standpoint, it is weaker, especially if you use 3 or more passes for the free space erase.

Joel

 

[cyberjackal]

By copying files you are doing the same thing as doing a pseudorandom 1-pass, before completing the procedure with your regular higher-security erase passes.

From a security standpoint, it is weaker, especially if you use 3 or more passes for the free space erase.

Joel

So you are saying, from a security standpoint, that using 3 or more passes are weaker than using pseudorandom 1-pass? Hmm, I'm not sure if I can understand this logic.

 

[Joel]

No, by copying and pasting you are doing something that's weaker than a 1-pass pseudorandom erase. I'm saying this weakness in security is even more significant if you do free space erasures with 3-pass or more erasures (I do 7)

Joel

 

[cyberjackal]

No, by copying and pasting you are doing something that's weaker than a 1-pass pseudorandom erase. I'm saying this weakness in security is even more significant if you do free space erasures with 3-pass or more erasures (I do 7)

Joel

So in other words, you don't approve of this suggested procedure, therefore I should disregard it. I thought this method was a good idea, but you know what? I think I'm going to test it using free recovery software, Recuva so I can verify whether the suggested procedure works or not.

 

[Joel]

It will work - but the strength in security is not there.

Joel

 

[Overwriter]

Hi cyberjackal

I understand what you are trying to do. It may be my feature request for Eraser to have the ability to create “ballast” files that you are thinking of.

Yes the creation of these ballast files to fill up most of the free space would indeed save time unnecessarily wiping free space that has never been used.

Example say you have a 200 GB dive and you are only using 100GB for everyday data. So when you come to overwrite your free space you have to write over 100GB that has never even been used wasting time and wear and tear on your drive.

My idea was to have a feature in Eraser that allowed the user to tell Eraser to (for this example) to make 100 x 1GB randomly filled files. This would fill the free space but crucially allow the user to delete 1 file at a time as and when they need the extra space.

I think Joels point here was to let you know that simply copying a file over the free space is equivalent to a single pass with Eraser. To gain more security perform a free space pass of your choice with Eraser then copy your ballast files to the free space so future wipes will be quicker.

As for you checking with any software based recovery tools it just won’t work as they will show the last copied file to the disk. The numerous passes that Eraser caters for and Joel was referring to are to are to defeat a more technical attack such as an electron microscope in a forensic laboratory etc, a million miles away from Recuva’s capabilities.