5 ms·
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:
by aw3c2 12y ago
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 lockscreen one, most users tend to use simple PINs or passwords (unless a device administrator enforces password complexity rules), which further facilitates bruteforcing. Android 4.4 replaced the disk encryption KDF with scrypt, which is much harder to crack and cannot be implemented efficiently on off-the-shelf GPU hardware. In addition to enabling FDE out of the box, Android L is expected to include hardware protection for disk encryption keys, as well as hardware acceleration for encrypted disk access. These two features should make FDE on Android both more secure and much faster.
- hhjj 12y agoblogspot is really annoying about that. Adding ?m=1 works here: http://nelenkov.blogspot.fr/2014/10/revisiting-android-disk-encryption.html?m=1 http://nelenkov.blogspot.fr/2014/10/revisiting-android-disk-...
- philjohn 12y agoThing 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-scrypt.html http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...
- kaoD 12y agoYour 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.
- comex 12y agoBut 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.
- TheLoneWolfling 12y agoThank you.
- blueskin_ 12y agoThank you for the sanity.