Free space file system
This page documents a hypothetical free space file system (FSFS) proposed by Sai Emrys on nb-discuss 9/23/09 and during a 26C3 lightning talk (slides). See that thread for more details and discussion.
It was codenamed 'Dandelion' by Mountain Sky, because of the way it lives "between the cracks" of its host file system (FS).
It is not currently implemented, just a proposal. If you feel like implementing it or have other ideas to contribute, please let Sai know (or just edit this page).
 Main idea
Dandelion is a covert storage system. It lives parasitically within a host FS by treating the blocks that the host FS considers unallocated as allocatable.
It allows the host FS to continue to allocate those blocks freely (except perhaps requesting a write lock during write operations to prevent race condition edit conflicts), treating such allocation as effective deletion of the block.
Of course, all data stored (including the index) is encrypted, thus requiring the key not just to read files but even to detect data's presence (though note vulnerabilities below).
Dandelion does NOT require:
- unmounting or making read-only the host FS
- allocating or reserving blocks on the disk (except perhaps temporarily for write operations)
- a special volume manager
- tampering with host FS files (except perhaps for a slack space index)
- being present for the creation of the drive and/or partitions
- leaving any space unaccounted for by a perfectly ordinary host FS
Dandelion's index (if it exists) would need to live either:
- in slack space (such as that provide by Rune, Waffen, KY, Data Mule, or MAFIA Slacker)
- in free space (thus requiring brute force search to find on boot)
- in RAM (thus completely destroying the Dandelion storage on reboot)
- out-of-band (e.g. in network storage or a USB key)
It may also be possible for Dandelion to not have an index. This would mean that listing all data present in free space requires brute force search, but various hash addressing schemes could make looking up some particular key still reasonably fast.
If Dandelion is not actively maintained, the natural churn of the host FS reallocating "free" blocks (that Dandelion was secretly using for data) will wipe out all of Dandelion's data. This provides for an automatic dead man switch; if Dandelion's control daemon is shut off (or not started on the next boot), it will completely disappear - no cruft left on the host FS.
Dandelion is not suited to reliable long-term storage. Depending on how replicated it is and how much the host FS wants to allocate, any particular datum may vanish at any time; it is similar to memcache in this regard.
Dandelion has two major vulnerabilities to detection:
- its control system must be stored elsewhere, and thus may be discoverable
- it makes free space look suspiciously random; normal free space would contain snippets of old files and be much less random
 Similar ideas
- Rubber Hose FS (main site)
- Deniable encryption
- Plausible deniability
- Rubber-hose cryptanalysis
- Mutually Assured Information Destruction
- NTFS Alternate Data Streams
- Slack space storage
- Steganographic FS
- Metasploit Slacker (screencaps)
- Data Mule FS
- Error coding
- TAHOE (among many other distributed storage systems)