Hector Martin

So in summary: random (long) numeric passcodes may be a more ergonomic choice for a given security level, especially if you force yourself to memorize the thing over a week or two (even if that involves carrying a post-it during that time.) But do whatever works for you.

Honestly, this is why I still prefer a (rooted) Android phone where you can set a long FDE passphrase and a simpler unlock passphrase. If you shut the thing down the key material is gone unless you can crack a long scrypted passphrase.

I understand the trade-offs Apple is making with their more complex security implementation (and Android is moving in that direction with file-based crypto) but I'd rather have a much simpler to analyze FDE approach.

The problem with FDE iirc was that for the phone to operate, keys must be in memory (so that binaries can be decrypted). The file based approach allow cleartext keys for non-essential files to be wiped from memory when the device is locked and to be encrypted with the passcode*

The OS is not encrypted, so the phone can boot and you can make emergency calls. However, to unlock the data partition (and thus boot the rest of the Android framework including all your user data) you need to type in your passphrase. This is a trade-off I'm willing to make.

Sure, but the key of the data partition is still in memory once you typed your passphrase at boot, right?

Yes. Ideally you'd want *both* schemes at once, but Google seems to think they can get fine grained data partitioning right (they can't) and thus forgo proper passphrase-controlled FDE when they use file-based encryption instead.

The reason why I prefer FDE is that runtime attacks are much more fragile - one misstep by the attacker and they're locked out, and the attack surface is smaller (physical attacks are very impractical if you can't shut the phone down); you have to get in through background SW.