[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C6FE8A5.30309@gnutls.org>
Date: Sat, 21 Aug 2010 16:54:29 +0200
From: Nikos Mavrogiannopoulos <nmav@...tls.org>
To: Kyle Moffett <kyle@...fetthome.net>
CC: Miloslav Trmač <mitr@...hat.com>,
Herbert Xu <herbert@...dor.hengli.com.au>,
linux-crypto@...r.kernel.org, Neil Horman <nhorman@...hat.com>,
linux-kernel@...r.kernel.org, David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 01/19] User-space API definition
On 08/21/2010 03:09 PM, Kyle Moffett wrote:
>> This patch introduces the new user-space API, <ncr.h>.
>>
>> Quick overview:
>>
>> * open("/dev/crypto") to get a FD, which acts as a namespace for key and
>> session identifiers.
>>
>> * ioctl(NCRIO_KEY_INIT) to allocate a key object; then generate the key
>> material inside the kernel, load a plaintext key, unwrap a key, or
>> derive a key. Similarly the key material can be copied out of the
>> kernel or wrapped.
>>
>> [...snip...]
>
> Ugh... We already have one very nice key/keyring API in the kernel
> (see Documentation/keys.txt) that's being used for crypto keys for
> NFSv4, AFS, etc. Can't you just add a bunch of cryptoapi key types to
> that API instead?
It is not that simple. My understanding of the keyring API is that it
allows exporting of the keys to user-space and this crypto API
explicitly prevents that, so enhancing the API that way will remove the
benefits of using it. It would be ideal to combine somehow those
solutions but this is more elaborate work than adding a bunch of new key
types. If anyone is interested in attempting that I'd be glad to help.
regards,
Nikos
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists