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! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1464697 Title: Enable encryption as per design mock up To manage notifications about this bug go to: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1464697/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
