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.
2
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
Replying to
How does it know which block is encrypted with a given key for block-based encryption? I can see how this could be implemented for higher-level filesystem-level encryption but I don't think either the ext4/f2fs approach or the ZFS approach provides incremental rekeying.
1
Replying to
Since dm-crypt is block layer encryption with 1:1 mapping between encrypted blocks and decrypted blocks, it isn't able to do it. It's possible if you actually have proper authenticated encryption but that requires having somewhere to store the extra metadata.
1
Replying to
A working block level FDE would address that before it got off the ground. Like by reserving some blocks out of band for tags.
1
Replying to
The ext2/f2fs encryption approach is essentially still block-based encryption by the way and they still need a global key for metadata. It's entirely possible to use with ONLY a boot passphrase and end result is essentially the same. They do encrypt every block when set up right.
The filenames actually get encrypted 2x because they encrypt the metadata blocks with the global key and then also encrypt the filenames with the per-file keys.
They don't currently have proper authenticated encryption in the mainline Linux kernel implementation either though.
2
Replying to
To me that pretty much entirely defeats the purpose. I have low confidentiality requirements, mainly to know if confidentiality has been violated (for credentials etc.) but high integrity requirement.