I have a brand new Nexus 5 from my work. As always, I care about the sensible data that is stored in the device. Luckily I've found the option of "Encrypt the phone". Sound great, doesn't it?
The instructions are quite straightforward: it can take up to one hour to encrypt the device, it can be protected by both a PIN code or a password and from the instructions seems clear that the whole device is encrypted and protected . OK. Great.
I was planning on having a long password or a pass-phrase since you only have to type it when the phone starts. In my laptop I use LUKS with a 25+ length password. I just have to type it just once and then I can lock my password using a 10+ key. I think this is good enough. The main idea is that you are trying to protect yourself from two different attacks:
- The normal screen lock prevents David Hasselhoff attacks and alike (Google it if you don't know what is it).
- The disk encryption prevents people from accessing my data doing brute force attack if the PC is stolen.
But with my phone I can't do that. First of all the password can be only 16 characters long. It could be better but is good enough. But the biggest problem is that the password for the disk encryption must be the same that unlocks the screen. Are we crazy?!! That sucks! In a regular day you unlock the screen dozens of times. You usually have a simple PIN, or pattern or password not a 16 characters long password :(
Oh! I almost forgot. By "Phone encryption" they mean "
encryption. It is not the whole device just one partition where is
supposed to be all the important information but.... how can I rely than
some applications are not saving the data somewhere else?
It seems that this limitation is a "usability feature" to prevent you to forget one of your two passwords. Great. The 16 bytes (characters) long password is another software limitation because they are using dm-crypt with a with 128 AES CBC and ESSIV:SHA256. They choose that the maximum of 16 bytes but there is no real limit until you reach 128 bytes. The master password is ciphered by the password provided by the user and using 2.000 rounds of PBKDF2 with a 128 random salt. The recommendation of OWASP is to use PBKDF2 with "a minimum of 64.000 iterations on 2012, doubling every two years as technology improves".
From this post of 2012  I get that you can do 71K PBKDF2 attempts per second. If you use a PIN number of 5 digits you need to test 10^5 = 100.000 combinations to get the password. 1.4 seconds. If you use a 6 characters (that you must type every time) password (not surpirsingly 10^6 = 1.000.000 bruteforce combinations) it takes 14 seconds. If you really want to type a 7 password long numeric password EVERY time you want to unlock the phone it will take 140 seconds to break the password.
It is not that different if you are using a password. Imagine that we are using a 6 characters lowercase letters. It would be 25^5=9765625 thats 139 seconds under 70K hashes/second. A 7 character password would take 24 hours to break. And you have to type those 7 characters every time you want to unlock the device! How annoying!
My point being that (from my understanding) that using the "phone encryption" feature on Android phones is useless if somebody wants to get to your private files, stored passwords and alike.
You can avoid the 16 characters long by rooting your device (hence avoiding the warranty) and manually setting up a password on the dm-crypt. And every time you change your PIN/Password you should re-configure the dm-crypt again. Quite useless.
Related and interesting posts/resoruces:
Anyway, that's my 5 cents on that. I'm looking forward to write more posts but I don't really have the time to write new stuff. I'm learning A LOT of new things at my job, a lot related with AWS and system administration in differents OSs. If I were studding I would publish a lot more but since almost everything is work-related I don't want to give information on how we do things at my company and writing stuff job-related feels like keep "documenting" what I'm doing in the job. I'll have to find something for publishing more because I miss it ^_^
 of dec. 2012. probably the actual rate is higher http://www.zdnet.com/25-gpus-devour-password-hashes-at-up-to-348-billion-per-second-7000008368/