On Fri, Sep 12, 2014 at 11:58:04AM -0500, John Goerzen wrote: > 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
I did most of the work in forking and rewriting Cryptfs as eCryptfs. I designed its encryption and key management, and I also wrote most of the initial release of the userspace toolchain. > 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. Each file gets its own randomly generated data encryption key known as a FEK. This key is wrapped with the wrapping key (FEKEK) retrieved from the user's session keyring. The signature for the FEKEK to use for newly created files is the ecryptfs_sig= mount option. By having the old FEKEK and the new FEKEK in the user session keyring and by mounting with the new FEKEK as ecryptfs_sig=, you will role both the FEK and FEKEK when you make a copy of any file. This isn't documented and there's no toolchain available to automate this at the moment. > After poring over poorly-documented things, I found a suggestion of how > to work around this: Agreed. Much documentation is definitely lacking. > 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. Agreed. Ubuntu distilled the complexity into a single checkbox in the installer, which gives a much more reasonable story for the typical desktop user. However there's still far too much technical detail exposed to the user, which has resulted in many users shooting themselves in the foot -- e.g., by naively deleting their ~/.ecryptfs directories in a misguided attempt to free up disk space. I'm taking the lessons learned from years of experience with eCryptfs out in the wild and seeing if I can do a better job in a file system native solution. > 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." The design was reviewed by industry-recognized cryptographers at IBM Research. > I also found mysterious bugs attempting to share the decrypted view of > an ecryptfs volume using NFS. The ideal of stacking in Linux was a nice fantasy, but it hasn't been realized in practice. NFS is one of several examples where it just hasn't worked out. That's one of the reasons why I'm currently working on a file system native solution. > Finally, encfs has an interesting reverse crypto mode where it > presents an encrypted FUSE view over a plaintext mountpoint. With eCryptfs, you would accomplish this by unmounting and then reading the encrypted files directly from the lower file system. > 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. MD5 has known weaknesses for specific applications. Those weaknesses have not been shown to apply to eCryptfs' use of MD5 in such a way so as to substantially reduce its security. That said, crypto attacks only get better, and so it's well advised to use a hash that isn't known to have significant weaknesses. I'm not motivated to update eCryptfs since I honestly would like to see it deprecated. > 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. Correct. This is one reason why I cannot currently recommend eCryptfs given attacks against encryption that lacks integrity that have surfaced in the past few years. My work with native file system encryption addresses this issue. Aside from lack of integrity and some stacking incompatibilities, there are a couple of correctness and performance issues with eCryptfs: * Since the kernel doesn't support stacking semantics, there's no mechanism to propagate a page invalidation from a lower inode page cache to the eCryptfs inode page cache. Unless you successfully hide all the dentry's for the lower inodes, eCryptfs can end up stomping over changes to the ciphertext -- i.e., by backup/restore utilities. * Actual file sizes are in the file contents. Which makes directory enumeration result in an open and read of every lower file, impacting performance. > 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. The incidentally lost or misplaced laptop is just about the only adversarial model that the currently available data-at-rest encryption options available for Linux can effectively address. Do not expect any currently available encryption solutions to help you much if you are individually targeted. > 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 If you're interested in my current work in ext4, here are my slides from this year's Linux Security Summit: http://kernsec.org/files/lss2014/Halcrow_EXT4_Encryption.pdf My current patchset implementing phase 1 (w/out integrity) is in the ext4 unstable branch: http://git.kernel.org/cgit/linux/kernel/git/tytso/ext4.git/log/?h=unstable If you have any suggestions from the distro integration side of things, including how keys should be managed and passed to the kernel, now would be a good time to let me know. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140916222943.ga30...@google.com
