[Cryptography] WIPEONFORK in Linux 4.14

[Henry Baker]

At 08:08 AM 11/25/2017, Jerry Leichter wrote:
>Granted, for some media, the only alternative may be file-specific encryption (which reduces, but doesn't eliminate, the problem:
>
>You still need to ensure that when you erase the key, it's *really* gone).

OK, guys, I'll bite.  What would be a simple design for an encryption system *whose only purpose is to avoid having to zero out file blocks when the file is deleted*?  I.e., if you have "access" to the directory metadata, then you can get the plaintext file contents.

Let's assume a trivial file system -- e.g., FAT32.

We have files allocated in lists of "clusters" of blocks.

We have special kinds of files called "directories", which encode an array of tuples (filename,metadata,ptr to list of blocks in FAT table).

Let's simplify further so that the files are each read-only (i.e., no update-in-place -- just rewrite the entire file).

If I have access to the file metadata, then I can utilize the per-file encryption key to read that particular file's data.

Now since a directory is also a file, it, too, must have a per-file encryption key, which is stored in the parent directory.

So by recursion, the root directory also needs a per-file encryption key.

Where is that root directory key stored?

Additional issues: so-called "atomic" file system actions cannot involve more than a small finite number of single-block operations.  So all of the intermediate states -- e.g., file partially allocated/written; file partially deleted -- must be handled safely and securely.