Comment 15 for bug 1464697

I'm sure this has already been discussed, but perhaps if "most of the work is ... to have an encryption solution implemented than we can enable/disable" at will... then an appropriate solution would be to:

1. always encrypt the userdata partition
2. by default (or when the encryption option is disabled) the password is blank or well-known
3. when the option is enabled, we simply swap the insecure non-password for the user credentials ala cryptsetup luksAddKey and luksRemoveKey

This is similar to how new Nexus and iOS devices do it (though they do it with a hardware register), and has the benefit of clear-text bits "never hitting the platters" (so to speak).

The major downside (as I see it) is that you incur the cyrpto performance penalty even if the option is disabled, but this is partially offset by:

1. the fact that this setup *retroactively* protecting one's user data who *later* decides it needs to be protected,
2. using the fastest cipher these little ARMs can push (e.g. salsa20 if they don't have AES acceleration), and
3. being able to somewhat reliably guess (on inexpensively test) if the luks password is blank, like using [keyslot-7] if it's blank or using a low/fixed iteration-count (which could be tested against)

Great work thus far, guys!