On Mon, Sep 6, 2010 at 11:50, Miloslav Trmac <mitr@xxxxxxxxxx> wrote: > ----- "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxxx> wrote: >> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote: >> > I have seriously considered the keyring API, and this is what I came >> up with - but I'd love to be shown a better way. >> >> FWIW adding a second key management system to the kernel is >> totally out of the question. >> >> If the existing system doesn't work for you, find a way to build >> on it so that it does. Adding a second system that pretty much >> does the same thing is unacceptable. > It does _not_ do the same thing, same as ramfs and file descriptors do not do the same thing although they are both related to files. > > The kernel keyring service is basically a system-wide data storage service. /dev/crypto needs a quick way to refer to short-lived, usually process-local, kernel-space data structures from userspace. The problem with the approach you're proposing is that we then have two entirely separate classes of keys. First we have the existing keyring class, which can be securely and revokably passed between different processes with limited rights, but cannot be handed up to the kernel's cryptoapi. Then we have your new class, which are anonymous keys with a brand new security model (which doesn't even have LSM hooks yet) and which cannot be referenced by name. Another potential issue is that keys are never actually "unnamed", in that sense. If encryption keys truly were "anonymous" then you would find it impossible to reliably decrypt the data on the other end. For example, every RSA private key should be indexed either by the X.509 DN or for bare SSH keys by the public modulus information. Even transient SSL session keys are always put into an SSL session cache by apache or whatever to allow them to be reused across multiple TCP streams! So I would argue that an SSL implementation that uses this should actually create or use a keyring specifically as an SSL session cache (with keys indexed by SSL session ID). It then becomes trivial to share an SSL session cache between 3 independent HTTPS server programs from different vendors, such that the compromise of *any* of the processes would not in any way compromise the security of the session keys. This would be especially true if the session keys are actually generated by a keyring+cryptoapi operation in the kernel. So my recommendation would be to create some new operations of the existing keyring code: (1) If you *really* care about anonymous transient keys that are not identified by an SSL session ID or similar, then add a keyring operation for "create an anonymous key in keyring X, where the kernel creates a proper temporary name". An SSL implementation would default to using the process-local keyring, which means that everything would automatically go away on process exit. (2) Add cryptoapi hooks to automatically register keyring key types based on the loaded cryptoapi modules. (3) Add any necessary keyring operations for efficiently performing zero-copy cryptoapi calls using those key types. Cheers, Kyle Moffett -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html