----- "Herbert Xu" <herbert@xxxxxxxxxxxxxxxxxxxx> 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. 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. Imagine that instead of thread = clone(..., CLONE_THREAD); you needed to do thread_fd = mkstemp("/proc/XXX"); fork(thread_fd); That's how "just using the existing keyring" would look like. Adapting the existing keyring to match the /dev/crypto use case better would make the keyring API at least 25% larger, and introduce completely different key identification and lifetime semantics for a set of keys. If you can see a way the two can be cleanly integrated, please don't just tell us that we have to do it, tell us how. > 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. The "key ID" is not embedded into encryption operation requests (it uses a struct nlattr), so it would be quite possible to supply the raw key instead. Mirek -- 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