Ext4 encryption [LWN.net]

Ext4 encryption

Posted Apr 9, 2015 15:49 UTC (Thu) by pr1268 (guest, #24648)
In reply to: Ext4 encryption by msnitzer
Parent article: Ext4 encryption

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.

to post comments

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 (subscriber, #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 (subscriber, #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.