On 09/06/2010 10:42 PM, Kyle Moffett wrote: >>> 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. I suppose you mean the reference to the internal representation of the key. This might be valid for few seconds until the required operation is over. This is not really what I would call storage. The storage and retrieval of keys is being done using two ioctl() the STORAGE_WRAP and STORAGE_UNWRAP. An example of how NCR works: 1. A Process generates an RSA key pair 2. Stores the (encrypted) pair using the STORAGE_WRAP to a file. 3. Another process loads the file, unwraps it using STORAGE_UNWRAP and gets a reference to the key 4. Does an RSA decryption using the key 5. Discards the reference to the key Consider the reference as a file descriptor after you have opened a file (a wrapped key). How do you see keyring being involved in a setup like this? > 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? In short: cryptographic operations. > 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? An unprivileged process will load a key from disk to kernel and use it. The keys leave the NCR framework only encrypted and authenticated. > Is it just a canonical interface for userspace to encrypt or decrypt > data using the kernel's CryptoAPI? I don't understand what do you mean by canonical, but this API can be used to perform crypto operations. It uses the internal linux API where possible. regards, Nikos -- 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
