Revisiting Android disk encryption • Hacker News Board

Re: Revisiting Android disk encryption

#31

Post by comex » Mon, Oct 06, 2014, 11:34 PM UTC

kaoD wrote: post #12

philjohn wrote: post #10

Earlier quoted context omitted.

Thing is, scrypt isn't a panacea - there are ways to make it CPU hard instead of memory hard - http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...

Your link repeats again and again (and again) that his criticisms only apply to password storage . In his own words "as a Key Derivation Function, it is still very much useful and secure" . As GP said, Android uses it as a disk encryption KDF.

But why do they only apply to password storage? In both use cases cracking proceeds by running a lot of possible passwords through the algorithm and doing a cheap verification operation at the end - "does using this hash as a decryption key produce something that looks like ext4" is more expensive than "is this hash equal to the one I have on file", but not by that much. I don't see why a way to compute the hash more efficiently on some class of device would not be a concern for use as a KDF.

Re: Revisiting Android disk encryption

#32

Post by comex » Mon, Oct 06, 2014, 11:39 PM UTC

jonknee wrote: post #24

higherpurpose wrote: post #19

Earlier quoted context omitted.

Google needs to solve that part of the problem. Apple has already solved it with TouchID. Google needs to do the same and mandate all OEMs must certify for fingerprint scanning technology (that has a high-standard of accuracy and security, not the gimmicks HTC and Samsung have tried before), or at least incorporate the same kind of technology Nymi uses in all Android Wear watches, so you can unlock the phones with th…

Touch ID still requires you to type in your password after you boot the phone. Still quite handy, but not a password replacement by any means.

I think the idea is that the password (which can be made complex if you don't have to enter it that often) is analogous to the "passphrase for the key", while Touch ID serves as the normal "passcode to unlock the device".

Re: Revisiting Android disk encryption

#33

Post by blueskin_ » Tue, Oct 07, 2014, 9:27 AM UTC

Very interesting. I've always been wary of PBKDF2 for these applications simply because most people will have a 4 digit PIN (although I don't), which is essentially useless against an offline brute force attack, and possibly worse than useless if it gives people a false sense of security.

At least CM11 allows a dedicated FDE password though - Google is really doing its users a disservice by not implementing this in stock Android.

Re: Revisiting Android disk encryption

#34

Post by blueskin_ » Tue, Oct 07, 2014, 9:28 AM UTC

aw3c2 wrote: post #2

The dreadful "you must enable Javascript for this plain website" layout strikes again. So here is the summary of the article for the fellow plain HTML lovers: > Android has included full disk encryption (FDE) support since version 3.0, but versions prior to 4.4 used a fairly easy to bruteforce key derivation function (PBKDF2 with 2000 iterations). Additionally, because the disk encryption password is the same as the…

Thank you for the sanity.

Re: Revisiting Android disk encryption

#35

Post by blueskin_ » Tue, Oct 07, 2014, 9:29 AM UTC

jareds wrote: post #13

I wonder if full disk encryption by default will render Android unusable to blind people such as my self? When I encrypted my Nexus 7 2012 running 4.4 it turns out that you are prompted to enter your password before the talkback screen reader starts talking. Needless to say this is a major issue and no one from Google appears to be interested in fixing it as far as I can tell. With my iPhone Voiceover comes up talkin…

Default still implies it can be disabled. As it is, I'd guess it wouldn't be that hard to store the TTS somewhere unencrypted and load that first, perhaps as part of the bootloader.