-2

I am wanting to securely wipe a file - of any type or format - obviously the File.Delete command in C# is no where near safe enough.

I seem to recall a post here (I can't find it again though!) that explained the modern File Systems (i.e newer than FAT32) can cause issues when attempting this kind of delete as they're a journaling file system and recovering data is far easier than in ye olden days.

After even more reading, I read it would be an idea to:

  1. Generate a random 256 bit encryption key.
  2. Encrypt FileA to FileB.
  3. Generate a new random 256 bit encryption key.
  4. Encrypt FileB to FileA.
  5. Repeat this n number of times to suit your level of paranoia.
  6. Use File.Delete to delete FileA and FileB.

This seems a logical way for encrypting/re-encrypting the data in the files over and over with keys that will never ever be recoverable or re-usable but is this actually a secure way? Will the file system overwrite the file at the same location/cluster (obviously the file will grow as it's contents are subject to encryption/re-encryption), ensuring the original content is overwritten?

Artjom B.
  • 61,146
  • 24
  • 125
  • 222
Jonny Wilson
  • 177
  • 4
  • 14

1 Answers1

1

Your approach won't necessarily solve your problem, and the problem doesn't only exist for journaling filesystems. (The old DOS undelete tool demonstrates that.)

Modern filesystems may move files around at any time, transparently to programs that are currently running, so juggling file content around doesn't guarantee that you won't be leaving an old copy of the file in a section of the disk that's marked unused.

You'd be better off using encryption directly rather than trusting that you can fool the OS into overwriting the old data.

asmecher
  • 1,055
  • 7
  • 12
  • And the answer is...? – Sani Huttunen Jun 05 '13 at 23:52
  • How do you mean using 'using encryption directly'? Files will be encrypted on the disk; but in a similar way, if I open a file, encrypt it, re-save it, won't there still be a possibility the FS could save the encrypted file in a NEW location, while leaving the old file in place albeit only in the FAT/journal? – Jonny Wilson Jun 05 '13 at 23:52
  • Sani, the answer is: you can't do this, so don't try. Jonny, I mean store the data encrypted in the first place. – asmecher Jun 05 '13 at 23:54
  • @asmecher: `a file - of any type or format` to me suggest all that encrypted or unencrypted files are eligable. So your answer still doesn't apply in regards of `encrypt all`. Your answer should be a comment, at most. – Sani Huttunen Jun 05 '13 at 23:56
  • This is OK, I am doing this where possible but the software I plan to release is a kind of 'retro fitted solution'. By this I mean the client has unencrypted files already which they want to start protecting/wiping, creating a VAULT folder to drop files into and automatically be encrypted. But by doing this, if I can't wipe the original at the original location, then this is a major problem with the solution. – Jonny Wilson Jun 05 '13 at 23:57
  • Sani, I've discouraged the original approach with an explanation of why, as it will at best provide a false sense of security; and I've suggested an alternative solution. Seems like an answer to me. – asmecher Jun 06 '13 at 00:04
  • @asmecher: Discouraging: OK. Alternate answer: Not OK. Verdict: Still a comment, at most. – Sani Huttunen Jun 06 '13 at 00:16
  • @JonnyWilson: OK. So the original location can be anything!? Like a `read-only` network resource? This question really needs to be closed and you need to get back to the drawingboard. – Sani Huttunen Jun 06 '13 at 00:24
  • I think the best solution here is creating the folder upon installation and then getting users to start using that folder - ensuring all files from therein are encrypted from the start. – Jonny Wilson Jun 06 '13 at 00:28