On Mon, May 17, 2021 at 04:25:15PM -0700, Omar Sandoval wrote: > > Well, assuming we're talking about regular files only (so file contents > > encryption, not filenames encryption), > > Yes, I was thinking of regular files. File operations using encrypted > names sounds... interesting, but I think out of scope for this. So the question I have is why would you want to get the raw encrypted data? One possible reason (and this is what Michael Halwcrow and I had tried designing years ago) was so you could backup a device that had multiple users' files without having all of the users' keys --- and then be able to restore them. So for example, suppose you had a tablet that is shared by multiple family members, and you want to be backup all of the data on the shared device so that it could be restored in case one of the kids drop the tablet in the swimming pool.... But in order to do that, you need to be able to restore the encrypted files in the encrypted directories. In practice, encrypted files generally exist in encrypted directories. That's because the typical way fscrypt gets used is we set a policy on an empty directory, and then all of the newly files created files have encrypted file names, inherit the directory's encryption policy, and then have encrypted file contents. So do you have the encryption key, or not? If you do have the encryption key, then you can ignore the issue of the file name when you open the file, but what's the reason why you would want to extract out the raw encrypted data plus the raw encryption metadata? You're not going to be able to restore the encrypted file, in the encrypted directory name. Perhaps it's because you want to keep the data encrypted while you're tranferring it --- but the filename needs to be encrypted as well, and given modern CPU's, with or without inline-crypto engines, the cost of decrypting the file data and then re-encrypting it in the backup key isn't really that large. If you don't have the encryption key, then you need to be able to open the file using using the encrypted name (which fscrypt does support) and then extract out the encrypted file name using another bundle of encryption metadata. So that's a bit more complicated, but it's doable. The *really* hard part is *restoring* an encrypted directory hierarchy. Michael and I did create a straw design proposal (which is too small to fit in the margins of this e-mail :-), but suffice it to say that the standard Posix system calls are not sufficient to be able to create encrypted files and encrypted directories, and it would have been messy as all hell. Which is why we breathed a sign of relief when the original product requirement of being able to do backup/restore of shared devices went away. :-) The thing is, though, just being able to extract out regular files in their raw encrypted on-disk form, along with their filename metadata, seems to be a bit of a party trick without a compelling use case that I can see. But perhaps you have something in mind? - Ted
