On 09/06/2010 02:17 PM, Herbert Xu wrote: > On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote: >> >> I can see almost no overlap between the two sets of requirements. Probably >> the only common use case is handling session keys (e.g. keys used in a >> kerberos ticket), which should be stored in the kernel for the duration of >> the session, made available to each process in the session, and available as >> keys for kernel crypto. Such keys will be in the minority, though, and it >> seems to me the best approach for handling these is to allow key >> export/import from/to keyring keys in addition to export/import from/to data >> in userspace: the long-term storage would be handled by the existing keyring >> API, which stores the key as unformatted binary data, and import into the >> crypto context would convert the key into the internal representation more >> suitable for crypto. >> >> 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. > > Also, the key management for secret keys that you've added should > not be the only mode offered to the user. Most people do not need > the separation between key setting and encryption/decryption.
I think this is a misunderstanding. The NCR does not have a keyring. The only common thing it has with a keyring is the word "key". The fact that it holds a reference to the key being used for encryption doesn't really make it a keyring. The kernel Keyring can be used with NCR to store keys as well as any other keyring. regards, Nikos -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
