It's important for the data-at-rest password to have lots of entropy. But using a long password for unlocking the screen annoys the user, and they will choose a shorter one. Therefore it's important to separate them.
See this open source app to set them separately: https://play.google.com/store/apps/details?id=org.nick.cryptfs.passwdmanager The screen unlock password is used for authentication while the OS is running, so throttling is enough to defend against password guessing. On 04/29/2013 12:09 PM, Seth David Schoen wrote: > Griffin Boyce writes: > >> Hashkill can now determine the master password for Android's full-disk >> encryption scheme. >> >> image showing the process: http://i.imgur.com/bFUf7lR.png >> script: https://github.com/gat3way/hashkill >> >> Thoughts? > > It seems like this is just a tool for doing dictionary and > brute force attacks against these passwords, not a class-break > that is inherently able to decrypt every single Android device. > > So, if your Android FDE passphrase is long and unpredictable > enough, this tool should still not be able to crack it. > > There are a lot of problems about disk encryption on small > mobile devices. One that was highlighted by Belenko and > Sklyarov at Black Hat EU 2012 is that mobile device CPUs are > relatively slow, so it's difficult to do very large numbers of > iterations of key derivation functions, which would make > brute-force cracking slower. > > http://www.elcomsoft.com/WP/BH-EU-2012-WP.pdf > https://en.wikipedia.org/wiki/Key_derivation_function > > The more KDF iterations that are used, the slower _both_ > unlocking by the legitimate authenticated user and offline > cracking will be. But if the legitimate user's device has > a slow CPU, the user may not accept the human-perceptible > delays that would result from using a lot of iterations. > > This tradeoff is a pretty fundamental problem. The user > wants to unlock their device using a very short, easy-to- > remember code. They want the device to be able to unlock > quickly when this code is entered, using information that > can be calculated from the code in a short time on a > comparatively slow mobile CPU. Then they also want someone > with a very fast cracking device like a desktop GPU not to > be able to brute-force that same code quickly. > > Belenko and Sklyarov also observed that some mobile crypto > applications were just not using KDFs at all or were using > them improperly, but I don't know of an indication that > that's true of the official Android FDE. Another problem > is that, especially if people are using touchscreens, they > may want a very short unlock PIN rather than a long > passphrase, which will inherently favor cracking. (For > example, if you imagine a system with a 5-digit numeric > PIN, you can quickly conclude that there is no number of > KDF iterations that will be acceptable to the mobile device > user and be a practical deterrent to a brute-force attacker > with even a single desktop GPU, at least for KDFs that can > be implemented efficiently on a GPU.) > > I don't think this problem is very well appreciated by > mobile device crypto users! > > Two ways to address this that come to mind would be using > tamper-resistant hardware (which apparently Apple is doing > for crypto in iOS devices) to store or generate the > decryption keys using cryptographic secrets kept inside > the particular device itself, and finding some way for > the user to somehow input a much higher entropy unlock > password. > -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech