If *no* applications care whether the filenames are encrypted or not, sure. But are you absolutely sure that no applications care? How do you know? And what is the advantage of not encrypting the filenames anyway? It is better to encrypt by default.File-name is a kind of File-system semantic and altering based on the on the user key context does not guarantee the system will be compatible with all their legacy applications.In theory we could make it optional whether or not file names are encrypted. But that means extra complexity, and extra complexity means potential bugs and vulnerabilities --- both potential implementation bugs, vulnerabilities caused by users getting confused by how they configure the system settings. So in general with security systems it's better to limit the complexity to the bare minimum.
That's right from the dev perspective. But for every security fix there is a convenience that is being sacrificed by the user. Providing a security fix even if there is no threat just adds pain to the user/solution and nothing else. Of course it all depends on the use case.
BTRFS has an experimental fscrypt implementation[1] which does not include the file-name encryption part it should be included but as an optional since not all uses cases saves sensitive information in the file-name. OR even if the attacker is able to identify a file called secrete.txt and break it then its still points at the weakness of the file-data encryption. Can we say that ? apparently from the discussion here it seems the answer is yes.
[1] Kernel: https://github.com/asj/linux-btrfs-fscryptv1
The only case which you've come up with in terms of potential vulnerabilities is backup and restore, and backup and restore is complicated for a number of numbers, since you need to be able to backup and restore not just the file name and the encrypted data blocks, but also the encrypted per-file key.
So getting this right will almost certainly require that the backup/restore software be fscrypt aware.
Not necessarily, as below..
Hence, making the encryption of the filenames optional doesn't just to make life easier for backup/restore isn't a compelling argument, since the backup/restore program is going to have to have special case handling for fscrypt protected file systems *anyway*.
fscrypt backup and restore does not work even without file-name encryption because the Extended Attribute needs special ioctl in the fscrypt (I did rise this objection before).
But its entirely possible to create a string based encryption metadata which can be updated/retrieved using the legacy backup tools such as
rsync --xattrs That will be a design for fscryptv2 probably..OR I mean to say possible optional file-name encryption is not the ground reason for the encrypted backup and restore challenge.
Thanks, Anand
Cheers, - Ted
-- To unsubscribe from this list: send the line "unsubscribe linux-fscrypt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|