Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking for file system with reasonably error corrections, but rugged against forensic after wipe.

Say, encrypted container via loop mounted like ext4 - journal file system. This is good performance and secure in many ways.

Wiping in this scenario is a destroying at least start of crypto-container(journal of ext4). It is fast. Recovering require huge of power: key + password + destroyed crypto-container's prefix.

Is there special file system with encryption and great wipe feature. "Great", I, mean fast and unrecoverable.

E.g. journal at start of file system contain not a addresses of files, but key - map of blocks randomly situated in memory area. Destroying of this key means destroying a sequences of whole file system. File in such file system is lay in un-fragmented memory's sequence. Plus whole of file system encrypted.

Wipe require rewriting the journal(map) of the file system only.

Say, rewrite map and key 30 tries, and no NSA, no NASA, no CIA can recovery wiped file-system.

share|improve this question

The right way to "wipe out" data is to use encryption: never let unencrypted data ever hit the disk. If you do that, then destroying the decryption key is sufficient to destroy the data. The decryption key is small and in many case you can keep it in RAM only (e.g. you type it upon boot, as a "password", which really means "a key that a human remembers"); if the key is in RAM and stays only in RAM, then destroying it is as simple as shutting down power (note, though, that RAM contents may resist loss of power for a few seconds or minutes).

File wiping is what you do when you did not do things the right way. You did write sensitive information on a physical medium, without any encryption. And you would like to "fix" that. There are three main problems with that:

  • File deletion does not overwrite the data on the physical medium; it just marks it as reusable for other files.
  • Sometimes, even writing over the data may not actually destroy it. This is where the so-called "file shredders" intervene, by overwriting the data several times with special patterns which ought to destroy all traces of the past data. However, such shredders are quite specific to the actual disk technology, and, in practice, quite specific to the technology used by disks 12 years ago; on modern disks, the shredders are likely to be useless and unnecessary. Conversely, with SSD, quite a lot of data can remain out of reach of the most thorough shredders. So file shredders are either total overkill or insufficient, with no middle ground.
  • Copies of parts of the file data can be stored in other areas. This may happen with virtual memory because the file data, before being in files, was in RAM. This may also happen with journaling filesystems (depending on the filesystem implementation and configuration).

So any solution based on file "wiping" is likely to be inefficient and incomplete. Anyway, despite this incompleteness, some people have tried to do some sort of automating shredding. This can be done at various level; this one does it by patching the unlink() C library function call (through an LD_PRELOAD trick). Statically linked process would still avoid it, though (but there are very few statically linked applications in a typical Linux installation). I would not recommend it (and the author himself is wary of it); notably, file-shredding on a SSD is not only ineffective (see above), but also noticeably shortens the lifetime of the said SSD.

share|improve this answer
thanx, but file-encryption is sometimes a little uncomfortable on standalone servers, that aren't reachable through local consoles; except you know of a method fo the following scenario:you have a virtual master that keeps the hd-keys to start virtual machines in memory. is there a solution to this? is this worth a question? – that guy from over there Sep 20 '13 at 18:15

There isn't a [main line] file system available that performs the way you describe/desire, mainly because it isn't very efficient as a file system. Doesn't mean that it is impossible, but that it just isn't often done and hasn't reached a common use scenario. In fact, what you describe is more like an encrypted file system than a quickly wiped one; more on that in a second.

While it isn't as "fast" as I think you're describing, the DBaN software (Darik's Boot and Nuke, provides an extremely successful wipe of data from physical magnetic media. I know this from experience performing data recoveries, including with low-level magnetic scanners. Once enough random data has overwritten your target data, the physical magnetic media is useless for recovery purposes.

For "fast" methods you have to utilize either full disk encryption (think TrueCrypt or Microsoft's BitLocker ) or physical disk destruction. The encryption "jumbles" the data so it is unusable without the private key. The destruction eliminates the physical media so there is no recoverable data (normally through degaussing the magnetic surfaces and then physically altering them so they are permanently unusable) Garner makes some good destroyers that will first degauss before drilling the platters. No one is going to be getting data off a drive after that.

share|improve this answer

With a system like rubberhose it would be extremely easy to destroy a file systrm. Just delete the master key for a rubberhose partition and it can no longer be decoded or even detected.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.