On Mon, May 17, 2021 at 10:53:16PM -0400, Theodore Y. Ts'o wrote: > 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? Thanks for the detailed response, Ted. I personally don't have a use case for reading and writing encrypted data. I only care about skipping compression/decompression, but early on it was pointed out that this API could potentially also be used for encrypted data. The question at this point is: if someone else comes along and solves the problems with restoring encrypted filenames, is this interface enough for them to restore the encrypted file data? It seems like the answer is yes, with a couple of additions to fscrypt. I should've been clearer that I don't have concrete plans to do this, I just wanted to leave the door open for it so that we don't need a second, very similar interface. Thanks, Omar
