Re: Allow encfs into jessie?
On 09/12/2014 06:46 AM, Jan Niehusmann wrote:
> A common use case for disk encryption is to protect a lost or stolen
> laptop. And the adversary is not some powerful agency, but a curious
> person browsing through the hard disk before formatting it.
>
> I see no reason to assume that encfs is not good enough for that use
> case, at the moment.
There is, of course, also the problem of: what will people replace it
with? I would suggest that some level of protection is better than
none, and that the most likely outcome of removing encfs is no
protection at all for a majority of users.
Probably the most common suggestion, and only real option I am aware of,
is ecryptfs. (LUKS and dm_crypt solve different problems.) Compared to
encfs, ecryptfs is extremely difficult to use. For instance, by
default, unlike encfs, you cannot change the password of ecryptfs data
because the passphrase is directly transformed into the encryption key.
After poring over poorly-documented things, I found a suggestion of how
to work around this:
1) Generate an encryption key with
od -x -N $bytes --width=$bytes /dev/urandom | head -n 1 | \
sed "s/^0000000//" | sed "s/\s*//g"
2) Pipe (I think!) the output from the above into
ecryptfs-wrap-passphrase to encrypt it
3) Before mounting, run ecryptfs-insert-wrapped-passphrase-into-keyring
pointing to the file saved in step 2
4) Save your precise mount options; in my case,
ecryptfs_unlink_sigs,ecryptfs_fnek_sig=longstringhere,ecryptfs_key_bytes=32,ecryptfs_cipher=aes,ecryptfs_sig=anotherlongstring
5) Use those precise mount options later
(These steps are rough; they may need a little tweaking but are close to
the mark.)
This is not friendly. At all.
Additionally, although the ecryptfs audit at
https://defuse.ca/audits/ecryptfs.htm produces fewer red flags than the
encfs audit did, still its conclusion says "there are some red flags
indicating it was not designed by a cryptographer."
I also found mysterious bugs attempting to share the decrypted view of
an ecryptfs volume using NFS. Finally, encfs has an interesting reverse
crypto mode where it presents an encrypted FUSE view over a plaintext
mountpoint.
I can't find anything in the ecryptfs manpages about whether they're
using SHA or MD5, but this RedHat bug from 2009 suggests it's using MD5.
https://bugzilla.redhat.com/show_bug.cgi?id=490918 I do not know
immediately why this was a red flag in encfs but not ecryptfs.
I should also note that even if the authenticity features of encfs are
less than perfect, it doesn't mean the package is useless. A person
may, for instance, care more about the encryption than MAC features.
>From what I can see, ecryptfs doesn't even have MAC at all.
Let's warn people about things, of course, but drop something that's
useful if not perfect? I don't think so.
Encryption, for a lot of people, is making onesself a harder target.
Let's face it, encfs, ecryptfs, dm_crypt, anything like that is probably
not going to completely protect a running Internet-connected machine
from every possible well-funded adversary, since once the encrypted data
is mounted, it is accessible until the machine is turned off. Physical
keyloggers, social engineering, etc. can also be a threat. None of
these tools is perfect, but they are all an *improvement*. If a laptop
is stolen from a coffee table by an opportunistic thief, and I know its
screen was locked and the data on it was encrypted by one of the above
tools, I can pretty much rest easy that at least my data is safe.
Transparent encryption can be an important layer of data security, but
it must not start or stop there for those truly concerned about it.
John
Reply to: