On Mon, Sep 6, 2010 at 17:11, Nikos Mavrogiannopoulos
wrote:
> 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
- "Kyle Moffett" wrote:
> On Mon, Sep 6, 2010 at 11:50, Miloslav Trmac wrote:
> > - "Herbert Xu" wrote:
> >> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
> >> > I have seriously considered the keyring API, and this is what I
> came
> >> up with - but I'd love to be sho
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 righ
On Mon, Sep 6, 2010 at 15:13, Nikos Mavrogiannopoulos
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 struct
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 pro
On Mon, Sep 6, 2010 at 11:50, Miloslav Trmac wrote:
> - "Herbert Xu" wrote:
>> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
>> > 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 seco
- "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
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
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
>
On 09/03/2010 11:18 AM, Herbert Xu wrote:
> I will be looking at this myself so please stay tuned and be ready
> to yell if you see that your requirements are not met.
On 08/20/2010 03:56 PM, Ted Ts'o wrote:
> So I'm bit at a list what's the whole point of this patch series.
> Could you explain th
- "Herbert Xu" wrote:
> Thanks for the updated patch-set. It does indeed fulfil some
> of the requirements raised earlier.
>
> However, as far as I can see this still does not address the
> extensibility. For example, say we want add an interface to
> allow the xoring of two arbitrary data
2010/9/3 Herbert Xu :
>> * ioctl(NCRIO_SESSION_INIT) to allocate a crypto session (to encrypt,
>> decrypt, hash, sign, or verify signature), then
>> ioctl(NCRIO_SESSION_UPDATE) to act on chunks of data. Deallocate the
>> session, and optionally retrieve session results (e.g. hash or
>> si
On Fri, Aug 20, 2010 at 10:45:44AM +0200, Miloslav Trmač wrote:
> This patch introduces the new user-space API, .
>
> 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 g
- "Kyle Moffett" wrote:
> On Fri, Aug 20, 2010 at 04:45, Miloslav Trmač
> wrote:
> > * 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
Nikos Mavrogiannopoulos wrote:
> 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
That's simple. Don't provide a read() key type operation, then.
David
--
To unsubscribe from this l
On 08/21/2010 03:09 PM, Kyle Moffett wrote:
>> This patch introduces the new user-space API, .
>>
>> 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
On Fri, Aug 20, 2010 at 04:45, Miloslav Trmač wrote:
> This patch introduces the new user-space API, .
>
> 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 ke
- "Stefan Richter" wrote:
> Miloslav Trmač wrote:
> > --- /dev/null
> > +++ b/include/linux/ncr.h
> [...]
> > +struct ncr_session_input_data {
> > + const void __user *data;
> > + __kernel_size_t data_size;
> > +};
>
> Why not using fixed-size fit-all members?
>
> struct ncr_session_inpu
2010/8/20 Stefan Richter :
>> +struct ncr_session_input_data {
>> + const void __user *data;
>> + __kernel_size_t data_size;
>> +};
>> +
>> +};
> Why not using fixed-size fit-all members?
> struct ncr_session_input_data {
> __u64 data; /* user pointer, cast to/from u64 *
On Fri, 20 Aug 2010 10:45:44 +0200 Miloslav Trmač wrote:
> +#define NCRIO_KEY_INIT _IO('c', 204)
> +/* generate a secret key */
> +#define NCRIO_KEY_GENERATE _IOWR('c', 205, struct ncr_key_generate)
> +/* generate a public key pair */
> +#define NCRIO_KEY_GENERATE_P
Miloslav Trmač wrote:
> --- /dev/null
> +++ b/include/linux/ncr.h
[...]
> +struct ncr_session_input_data {
> + const void __user *data;
> + __kernel_size_t data_size;
> +};
> +
> +struct ncr_session_output_buffer {
> + void __user *buffer;
> + __kernel_size_t buffer_size;
> + __
This patch introduces the new user-space API, .
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
22 matches
Mail list logo
