On Tue, Apr 14, 2015 at 06:18:41PM +0200, Christoph Hellwig wrote: > Also for something that while only > implemented in one filesystem has pretty broad API implications I'd > really expect a generalist VFS review (I plan to get to it ASAP..). There really isn't much of an API. We have an ioctl to set the encryption policy (which currently is only which encryption key and the encryption modes to be used) on an empty directory, an ioctl to fetch the encryption policy, and an ioctl to get a per-file system password salt[1] (to protect against rainbow tables). We *know* that the API will be need to be extended to support more complicated encryption policies (i.e., the use of public key, files that can be read by possessors of more than one key, etc.), but we also know we're not smart enough to figure out what that API will look like right now. So that is something that will have to be extended later, almost certainly with a new ioctl. So I've designed the existing interface to be things that can be easily supported into the future, and if the existing interfaces are only supported by ext4, and someone else wants to design a new system call, and argue about x509 vs GPG certificates for the future use of public key crypto, that's fine. I just don't want the patches to be delayed while the interface bikeshedding party is going on. :-) - Ted [1] Note that the use of the password salt, and the string-to-key algorithm specified by NIST SP800-132, is purely optional. It's what the e4crypt userspace tool happens to use, but if you want to use your own string-to-key algorithm, or just use bare AES keys, a userspace tool can always do that. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
