Don't build encryption tools where it's non-obvious to the user that they don't actually possess the key. 😡
Conversation
There should have been no way to get to that situation without:
1. Being offered the option to use the passphrase as input to a KDF, with warning about strength.
2. Being warned to store key backup on paper, and that data WILL BE GONE PERMANENTLY if you don't.
1
3
Replying to
They do use a KDF but only use the resulting key to encrypt the header. It's the approach used by most disk encryption implementations in order to allow the user to rotate the password without having to encrypt the whole drive again, only the header. Easy to make that atomic too.
2
1
Replying to
If you do that, rotation has weaker security properties. You really do need to reencrypt everything to rotate key without preserving any weakness.
1
Replying to
Sure, but the user wanting to change their passphrase is different than them wanting to rotate the underlying disk encryption key. It could require a lot of time and storage space or simply backing up, resetting and restoring from the backup.
It's also worth noting that some devices have an SoC key wrapping feature where the OS can choose to provide the encrypted key and key derivation inputs for the key encryption to the SoC encryption module without ever being able to see the decrypted disk encryption key itself.
1
That's how it works on iPhones. Snapdragon has a similar hardware feature and AOSP supports it but it's not actually used on the reference devices (Pixels) probably because they prefer being able to verify that the inline encryption support is actually working as intended.
1
Show replies
Replying to
No, you can rekey incrementally in background by just having two active keys. Same way wireguard can rekey nondisruptively despite udp being out of order.
2
1
Passphrase change without rekey may be desirable, but for that capability, user should be prompted & urged/warned to export & backup key. Systems that don't allow that are user-hostile.