Ext4 encryption [LWN.net]

Ext4 encryption

Posted Apr 9, 2015 12:44 UTC (Thu) by felixfix (subscriber, #242) [Link]

Is it a matter of which pages are used for the decryption? If, say, an internal buffer is used in one method while a mapped page is used in the other, the internal buffer could be a bottleneck requiring a lock, while the mapped page may cause a dirty page to be flushed.

I am just brainstorming, no idea of what I am talking about. Please be gentle :-)

Ext4 encryption

Posted Apr 9, 2015 13:41 UTC (Thu) by msnitzer (subscriber, #57232) [Link] (12 responses)

As the primary DM maintainer I've yet to see a single report about dm-crypt performance being a pain point for android. Yet ext4 developers have gotten to a point where AOSP changes were introduced to use their newly crafted encryption support. Amazing really.

Ext4 encryption

Posted Apr 9, 2015 15:49 UTC (Thu) by pr1268 (guest, #24648) [Link] (6 responses)

Are you suggesting that the Android folks ignored your (presumably serviceable and efficient) DM-Crypt code and decided to write their own?

I'm not trying to ruffle feathers here; I'm sincerely curious why a community of developers would go out and re-invent the wheel. Kinda like how we're up to 1500 programming languages—because whoever wrote the Nth programming language did so because the other N-1 were "broken". Sigh.

Or...

<CONSPIRACY THEORY>Your DM code lacks a back door.</CONSPIRACY THEORY> (hint, hint!)

Perhaps I'm comparing apples and oranges with the programming languages analogy, but my jaded attitude towards the plethora of languages is real.

Ext4 encryption

Posted Apr 9, 2015 16:08 UTC (Thu) by msnitzer (subscriber, #57232) [Link] (1 responses)

I really have no idea. Filesystems yielding functionality to block devices tends to make filesystem developers uneasy (any excuse to avoid it). Fosters NIH syndrome. But to be fair, there are efficiencies to be had with a filesystem natively providing functionality. Same efficiencies can be had with fs+block integration but it takes more work/coordination that is less comfortable for filesystem developers.

I'm not convinced there isn't a way to make dm-crypt work perfectly well for andoid's needs -- but that is purely my naive position considering I'm uninformed about their motivations/requirements.

Ext4 encryption

Posted May 22, 2015 9:59 UTC (Fri) by xnox (guest, #63320) [Link]

http://nelenkov.blogspot.ru/2012/07/using-app-encryption-...

Ext4 encryption

Posted May 27, 2015 5:37 UTC (Wed) by geofft (subscriber, #59789) [Link] (3 responses)

dm-crypt is block-level encryption, not filesystem-level encryption. This means that you cannot add any bytes in the process of encrypting it. This means that your encryption is not authenticated, and unauthenticated encryption is generally a major mistake.

dm-crypt is very good at what it does, but what it does is necessarily incomplete by the nature of the problem. There are (limited) use cases for unauthenticated disk encryption, and dm-crypt is great for those, but if you can do authenticated encryption, you should. It's sorta like unsalted, unstretched passwords: SHA-512 is a fantastic hash function, but using it as a password storage scheme makes for a bad password storage scheme.

I see your conspiracy theory and raise you "The NSA is sending shills into comment sections to complain about people writing good cryptosystems instead of reusing the bad cryptosystems they already know how to break."

Ext4 encryption

Posted May 27, 2015 16:10 UTC (Wed) by flussence (guest, #85566) [Link] (1 responses)

I can think of a more mundane explanation: Android devices have all the software necessary to flip dm-crypt usage on/off in-place, but lack the hardware (battery capacity) to do it safely.

Ext4 encryption

Posted Jun 22, 2015 17:09 UTC (Mon) by luto (guest, #39314) [Link]

It would be straightforward to do it in place in a resumable fashion using a mix of dm-crypt, dm-linear, and whatever the dm target that delays IO is. All you'd need to do is have a little bit of spare space and some user code.

Ext4 encryption

Posted May 27, 2015 18:26 UTC (Wed) by kmeyer (subscriber, #50720) [Link]

> dm-crypt is block-level encryption, not filesystem-level encryption. This means that you cannot add any bytes in the process of encrypting it. This means that your encryption is not authenticated, and unauthenticated encryption is generally a major mistake.

Ext4's new encryption mode, as described, is equally unauthenticated -- it is not designed to be resilient against covert modifications to the ciphertext.

Ext4 encryption

Posted Apr 10, 2015 21:57 UTC (Fri) by mhalcrow (guest, #17371) [Link]

Mike, as you suggest, I don't expect we'll be able to realize a significant performance boost for raw unauthenticated (XTS) encryption by doing it in ext4 rather than the block layer.

Down the road, I do think we'll be able to implement authenticated encryption more easily than a dm layer mechanism will, because we've got existing transactional facilities to give us consistency between the crypto metadata and the ciphertext, and we expect to get per-block metadata support from Mingming when it's ready. I've got a roadmap for that, but we're taking this one step at a time and doing unauthenticated crypto first.

Once we start talking about managing additional per-block metadata with transactional semantics, we're pretty far into "file system" territory. With that extra data, we'll need to make some decisions around I/O patterns, memory usage, and so forth. The file system is the best place to manage that sort of complexity.

If you've got a single-user laptop that's subject to being left in a taxi, FDE like dm-crypt makes a lot of sense.

If it's more complicated than the single-user laptop story, you often need to jump through hoops to make it work with FDE. Pushing a key into the keyring and setting a policy on a directory for an existing file system vastly simplifies many scenarios. Multi-user environments such as Android, Chrome OS, and Cloud servers are targets for encryption that can be selectively enabled and managed on shared live mounted file systems with multiple users.

Ext4 encryption

Posted Apr 12, 2015 5:46 UTC (Sun) by hobarrera (guest, #101888) [Link] (2 responses)

From what I can well, these changes allow per-directory-tree keys/passwords. Can dm-crypt do that? Maybe the Android folks needed/wanted that for some reason or another (I can't guess why, though).

Ext4 encryption

Posted Apr 14, 2015 17:38 UTC (Tue) by chloe_zen (guest, #8258) [Link] (1 responses)

One of the weaknesses of full-disk encryption is that once any user logs in the whole disk is effectively in plaintext; all an attacker needs is privilege escalation. Directory tree encryption is *the* killer feature here.

Ext4 encryption

Posted Jun 26, 2015 12:44 UTC (Fri) by yoshi314 (guest, #36190) [Link]

separate encryption per each user-profile, that's one use case i am thinking about.

Ext4 encryption

Posted Jun 22, 2015 16:18 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

Oh!

Now that’s… puzzling.

They have different use cases of course: a per-file nonce instead of a per-block nonce, and differing keys, which is kinda neat, but I’d actually expect dmcrypt to perform *better*.

Ext4 encryption

Posted Apr 9, 2015 18:25 UTC (Thu) by job (guest, #670) [Link] (1 responses)

I agree. I don't understand why dm-crypt and ecryptfs are lumped together in the article, neither what the use case of only encrypting file name and contents is. Is it for unauthenticated users to be able to delete files?

Corbet's articles are usually much more enlightening. How about a follow up article, with a little more details?

Ext4 encryption

Posted Apr 10, 2015 22:00 UTC (Fri) by mhalcrow (guest, #17371) [Link]

It is for users without the key to be able to delete files. In one scenario, the Chromium OS user cache management system needs to be able to delete other users' cache files while they aren't logged in. That's why they're using eCryptfs for the user cache right now.

Ext4 encryption

Posted Apr 12, 2015 5:45 UTC (Sun) by tytso (subscriber, #9993) [Link]

Yeah, this article is missing a few bits of context.

There are two major advantages of doing encryption in at the file system level.

1) We don't have to worry about encrypted and unencrypted pages hanging around in the page cache. We do need to use bounce pages on the writepage path, but they get released right after the I/O is complete. This is a bit harder to handle with ecryptfs because it uses a stacking file system paradigm.

2) We can use multiple keys so that each user and/or work profile can be encrypted with a single key. This is something you can't do with dm-crypt, and it's important if you want to be able to flexibly share space between multiple users who are mutually suspicious with each other. In the chrome OS case, the user who is logged in can send a request to a root daemon for more disk space (if free disk space is running low), and the root daemon can delete files from that cache directory of some other user who is currently not logged in.