[JoshTriplett]

I've read that page before. It does a good job of explaining why you don't (just) want full-disk encryption, and explaining why developers might want to use application-level crypto in their own application. However, what it doesn't explain is "what should users (developer or otherwise) do to encrypt all the random files on their system?".

Full disk encryption has the advantage of being transparent and not application-specific, so you don't have to teach every random application to do application-level crypto.

Sure, if you have a few specific files you want to encrypt, you could run gpg. You could even teach specific tools to understand gpg, such as text editors that can decrypt to memory, edit, and re-encrypt before writing to disk. But what about a source tree, stored in a git repository, regularly manipulated with git and various command-line utilities, and edited with a variety of editors? How would you store that, securely, other than on a block device encrypted with full-disk encryption?

Would you suggest a file-level encrypting filesystem instead, similar to eCryptFS? Would you suggest integrating encryption into ext4 (currently being worked on) and other filesystems?

[belorn]

Application-level crypto work great when the target surface is small and known, but fails badly otherwise.

Take a email you have received on a unix mail server, and lets assume it was sent encrypted. Is the search term database encrypted, the one that was created while the mail was decrypted? Is the reply you sent encrypted while resting in the sent directory? Are there logs, metadata, offline caches and similar leakage of data?

One should start with full-disk encryption, then add application-level encryption for defense in depth.

[lurkinggrue]

I can imagine all the ways an os can leak information if it isn't fully encrypted at a sector level.

Just having the filnames is an serious risk.

[kngspook]

I spent all last night searching for an answer to this question. I couldn't find one.