Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri Mar 16 02:16:49 CET 2018
On Fri 2018-03-16 11:58:45 +1100, gnupg at raf.org wrote:
> Daniel Kahn Gillmor wrote:
>> or, if what you really care about is file-level encryption on a
>> GNU/Linux desktop and you *don't* care about files being OpenPGP
>> formatted, you could look into ext4's native encryption features (see
>> e4crypt(8) and related docs to get started).
> yes, luks full disk encryption would be best of course but if
> boss says no, ecryptfs file system encryption might be
> acceptable. every file in an ecryptfs-mounted file system is
> individually encrypted. encrypting their names as well is
> optional. and it's easy enough to setup. and i haven't detected
> any performance penalty (except when running du, just don't).
> and i'm fairly sure ubuntu has this built-in for home directory
> encryption but i don't know which versions.
note that for fike-level encryption, i was not talking about ecryptfs,
but rather about e4crypt. these are different technologies, and i would
suspect (though i haven't profiled it) that e4crypt would be
significantly more performant than ecryptfs.
fwiw, i think that block-device level encryption (e.g. dmcrypt with
LUKS) is orthogonal to file-level encryption (e.g. e4crypt). they have
different use cases against different adversaries, and there's no clear
argument that i've seen that you shouldn't use them in concert with one
for example, consider the "fast secure delete" functionality that you
get from file-level encryption -- delete the inode of a file (which
contains the file's key) and then the on-disk data for the file will be
unrecoverable. this isn't achievable with block-device-level crypto --
as long as the block device is unlocked, the old blocks are still
More information about the Gnupg-users