On Mon, Sep 6, 2010 at 15:13, Nikos Mavrogiannopoulos <n.mavrogiannopoulos@xxxxxxxxx> wrote: > On 09/06/2010 08:00 PM, Kyle Moffett wrote: >>> 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. > > I don't think this is the case. The NCR does not store any keys nor > retrieves them. It does delegate the burden of that to userspace > application. NCR exports a wrapped version of the key and the userspace > application stores it. It could use the keyring to store the keys or > could directly store them in the filesystem. Hmm, I'm confused. You say "The NCR does not store any keys nor retrieves them", but ~75% of your API is specifically related to storing keys into kernel memory or retrieving them out of kernel memory. Specifically, putting keys into and out of the kernel and passing them around between processes is the *whole point* of the keyring API. So let me ask for some clarification: You talk a lot in the patches about the API itself, but what is the intended *use-case* for NCR? Is it to provide a back-end for code such as enhanced-security OpenSSL libraries? For example, a privileged process would loads a key from disk into the kernel, then fork the unprivileged SSL server process? Is it just a canonical interface for userspace to encrypt or decrypt data using the kernel's CryptoAPI? 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
