

Ext4 encryption patches for Android - xrstf
http://thread.gmane.org/gmane.comp.file-systems.ext4/48206

======
2bluesc
Dug in trying to understand what's wrong with dm-crypt (+ LUKS on my desktop)
I use on Android already. No _real_ answers.

Interesting quote from dm-crypt dev:

> 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.

ref: [https://lwn.net/Articles/639736/](https://lwn.net/Articles/639736/)

No real answers or benchmark data. Anyone know why I'd want to use this over
dm-crypt?

~~~
saurik
This is about trying to "catch up" to the encryption Apple has in HFS+. On
iOS, there are a number of different policies that can protect a file: it can
always be accessible, be accessible only after the user first unlocks their
device, or only be accessible while the device is unlocked. The ability to say
"I have locked my device: destroy the in-memory keys used to decrypt most of
my data" is really powerful and important, as otherwise I can attack your
running phone that I steal out of your pocket to obtain your data. This kind
of flexibility just doesn't fit at the level of a block device.

------
ckuehl
Is there a security benefit to encrypting at the filesystem layer as opposed
to just encrypting the underlying block device (like dm-crypt)? It seems like
whole-disk encryption would be much harder to accidentally implement
insecurely.

~~~
ianburrell
Whole-disk encryption is simpler, but less secure than filesystem level
encryption. Block level encryption can't protect against active attacks
because it doesn't have the extra space to store checksums. Algorithms are
much more vulnerable when the attacker can make modifications and see the
response. This makes disk level encryption only suitable for protecting
against your laptop being stolen.

Don't know if ext4 encryption supports it, but the filesystem could allocate
extra space for checksums to verify files aren't being modified. It also could
store different keys for each file or directory making it possible to lock and
unlock portions of the filesystem separately.

~~~
hobarrera
> Algorithms are much more vulnerable when the attacker can make modifications
> and see the response.

That means having access to the block device itself, with the system in an
unlocked state.

If you've reached that scenario, then it's game over for whatever data is
being encrypted.

------
mschuster91
Heh, if anyone with access to the design document reads this, I get an "access
denied" error on the Google Doc mentioned in the mail.

~~~
corbet
Try
[https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npa...](https://docs.google.com/document/d/1ft26lUQyuSpiu6VleP70_npaWdRfXFoNnB8JYnykNTg/edit#heading=h.fctvdc89s0kl)
instead. Or LWN's take at
[http://lwn.net/SubscriberLink/639427/5357c92c58eb584a/](http://lwn.net/SubscriberLink/639427/5357c92c58eb584a/)
.

