Why does Eraser not erase encrypted files?

FlyingHawk

FlyingHawk

New Member
I have files encrypted using EFS on Windows 7. I've used other file shredder software that can erase these files no problem, even without administrator privileges.
I say this not because these other software didn't report error, but because I did the test on a small partition, where I could locate the sectors storing the encrypted file, and actually watched the data of what used to be the encrypted file replaced with new random data. The same didn't happen with Eraser 6.2

Is there any technical difficulty to erase encrypted files (read/write access shouldn't be a problem with the correct user account)? Or is it simply designed as a way to speed up the erasure process?

In any case, I think a proper file shredder program should erase encrypted files as well.
Of course, the other software I mentioned also have their own limitations (Freeraser - not erasing file names; HxD - not erasing cluster tips).
 
When EFS encrypts a file, it copies its contents into a temporary hidden file. It then encrypts by blocks and writes the encrypted data into the original file. After the process is done, the temporary file is deleted. To guarantee erasure of the file you need to wipe the freespace and the file itself. The keys to the encryption/decryption are stored on the local PC which makes the whole effort pointless. If you want encrypted files you should use Truecrypt/Veracrypt and do it at the block level.
 
Thanks for the reply.

I do use VeraCrypt for more sensitive/high-risk files/drives. I'm aware of EFS's weaknesses and it's only my secondary protection. And I think EFS's key is not directly stored on disk, but ultimately protected by the user's login password, whose hash is in the SAM database which can be further protected with SysKey utility. All offline key recovery attacks on EFS I know of involve some attacks on the SAM database.

Back to my original question.
If I understand you correctly, it's not so much a technical difficulty, but a design to avoid giving users a false sense of security. But I don't think not erasing encrypted files is the right way to do it.
For all Eraser knows, I could have wiped the drive right after the encryption, or maybe the file isn't even encrypted on this drive at all but encrypted on some other drive and copied here. Maybe I know that's the only copy of my file I need to erase. Refusing to erase the file in this case only causes inconvenience and doesn't really help me.

Furthermore, if Eraser really wants to avoid giving users a false sense of security, it has already failed. In my test, when I edit a(n unencrypted) text file, I see (from HxD) that the original version of the file is not modified, but a new copy of my edited file is created somewhere else on my disk. Maybe it's a shadow copy feature or something. But when Eraser happily erased the file without any warning, it only erased the new version but not the old version which is still on disk in plain text.

My point is, there is only so much Eraser can do to protect its users. How much security a user can achieve really depends on the user. If Eraser suspects unsafe practice, it's fine to pop up some warnings, BIG RED ALL CAPS warnings if you like. But not doing what it could do only causes inconvenience for users who know what they're doing.
 
>>it only erased the new version but not the old version which is still on disk in plain text.
Eraser only erases what it is told to erase. For temp files or deleted shadow copies we have the freespace erase option.
 
muscas said:
>>it only erased the new version but not the old version which is still on disk in plain text.
Eraser only erases what it is told to erase. For temp files or deleted shadow copies we have the freespace erase option.
Click to expand...
Yes, I understand that. That's fine. I'm NOT complaining about it not erasing hidden copies. I'm only using this example to show that it doesn't make sense to not erase a particular copy of an encrypted file when I specifically ask Eraser to. Your reply actually build to my case, because I'm NOT asking it to erase all hidden copy/remnant of the encrypted file.

If there's any technical difficulty, that's a different story, but I'd also like to know.
 
As a test, I created an Adobe Acrobat 256-bit encrypted file. The file remained completely intact and visible after erasure.
Eraser version: 6.2.0.2970
Platform: Windows 10 Pro
Antivirus: None
 
I think now I know why Eraser doesn't erase compressed, encrypted and sparse files - there are indeed technical difficulties.

From "How SDelete Works" in SDelete:
If a program writes to an existing portion of such a file NTFS allocates new space on the disk to store the new data and after the new data has been written, deallocates the clusters previously occupied by the file... Thus, overwriting such a file will not succeed in deleting the file's contents from the disk.

So erasing compressed, encrypted and sparse files is indeed more difficult and apparently Eraser hasn't implemented a way to do this.
Would be nice if admins on the support forum can cut to the chase and actually answer questions, instead of beating around the bush and lecturing users on file security that they already know.
 
You must log in or register to reply here.
Back
Top