Hi Stephan,
>> So if a server has public/private key pair, then the first thing that should
>> the server do is load this key pair into the kernel and retrieve a key
>> serial for it. And then use this key id to derive the session key. That
>> session key can then be used with AF_ALG and skcipher
Hi Stephan,
>> This adds support for a new socket options called ALG_SET_KEY_ID that
>> allows providing the symmetric key via a key serial from the keys
>> subsystem.
>>
>> NOTE: Currently we do not have a dedicated symmetric key type and using
>> the user key type is not optional. Also lookup_u
On Wed, 2015-10-28 at 02:18 +0100, Stephan Mueller wrote:
>
> But having a tie between both, the kernel crypto API and the key system, that
> cannot be cut any more is something I am not sure about. Both should and
> would
> work in isolation of each other as both serve different needs.
Sure,
Am Mittwoch, 28. Oktober 2015, 09:46:51 schrieb Marcel Holtmann:
Hi Marcel,
> So if a server has public/private key pair, then the first thing that should
> the server do is load this key pair into the kernel and retrieve a key
> serial for it. And then use this key id to derive the session key.
Am Mittwoch, 28. Oktober 2015, 09:37:02 schrieb David Woodhouse:
Hi David,
> On Wed, 2015-10-28 at 00:47 +0100, Stephan Mueller wrote:
> > Ohh, I see. So, you are saying that there should not be a setpub/privkey
> > for the akcipher AF_ALG interface?!
> >
> > If somebody wants to use akcipher, h
Am Mittwoch, 28. Oktober 2015, 02:02:51 schrieb Marcel Holtmann:
Hi Marcel,
> This adds support for a new socket options called ALG_SET_KEY_ID that
> allows providing the symmetric key via a key serial from the keys
> subsystem.
>
> NOTE: Currently we do not have a dedicated symmetric key type a
This adds support for a new socket options called ALG_SET_KEY_ID that
allows providing the symmetric key via a key serial from the keys
subsystem.
NOTE: Currently we do not have a dedicated symmetric key type and using
the user key type is not optional. Also lookup_user_key() is currently
private
Am Mittwoch, 28. Oktober 2015, 01:09:58 schrieb Stephan Mueller:
Hi Harsh,
>
>
> However, any error in user space should not crash the kernel. So, a fix
> should be done. But I think your code is not correct as it solidifies a
> broken user space code.
After thinking a bit again, I think your
Hi Stephan,
>>> Albeit that all sounds like the crown jewel, how do you propose that shall
>>> happen?
>>>
>>> Assume that you have a web server that has a pub and priv key in its
>>> current configuration -- I guess that is the vast majority of configs.
>>>
>>> Can you please elaborate how the
On Wed, 2015-10-28 at 00:47 +0100, Stephan Mueller wrote:
>
> Ohh, I see. So, you are saying that there should not be a setpub/privkey for
> the akcipher AF_ALG interface?!
>
> If somebody wants to use akcipher, he shall set the key via the keyring and
> akcipher shall obtain it from the keyrin
Am Montag, 26. Oktober 2015, 14:51:01 schrieb Harsh Jain:
Hi Harsh,
> Hi Stephan,
>
> I tried 1 more patch. This time result is correct. Find attached patch
> file. Is there any side effect of this patch.
The strace is enlightening.
The user space code does an accept on an already accepted FD
Am Mittwoch, 28. Oktober 2015, 08:43:16 schrieb David Woodhouse:
Hi David,
> > Albeit that all sounds like the crown jewel, how do you propose that shall
> > happen?
> >
> > Assume that you have a web server that has a pub and priv key in its
> > current configuration -- I guess that is the vast
On Wed, 2015-10-28 at 00:35 +0100, Stephan Mueller wrote:
> Am Mittwoch, 28. Oktober 2015, 08:15:16 schrieb David Woodhouse:
>
> Hi David,
> >
> > Absolutely. The interface needs to support *both*.
> >
> > I've spent a lot of time chasing through userspace stacks, fixing
> > broken assumptions t
Am Mittwoch, 28. Oktober 2015, 08:15:16 schrieb David Woodhouse:
Hi David,
>
>Absolutely. The interface needs to support *both*.
>
>I've spent a lot of time chasing through userspace stacks, fixing
>broken assumptions that we will *always* have the actual key material
>in a file — and making libra
On Tue, 2015-10-27 at 11:50 +0100, Stephan Mueller wrote:
>
> >expose that critically limited API to userspace. We need to expose an
> >API which supports hardware keys, and basically that means using the
> >kernel's key subsystem.
>
> Agreed. But at the same time, that interface should be able t
Hi Marcel,
On 10/26/2015 09:54 PM, Marcel Holtmann wrote:
> after having discussions with David Howells and David Woodhouse, I don't
> think we should expose akcipher via AF_ALG at all. I think the akcipher
> operations for sign/verify/encrypt/decrypt should operate on asymmetric keys
> in the f
Am Dienstag, 27. Oktober 2015, 18:19:01 schrieb David Woodhouse:
Hi David,
>
>That's largely orthogonal to the point Marcel was making.
>
>The point is that akcipher is limited to using keys for which we have
>the private key material available directly in software. We cannot
Agreed.
>expose tha
On Tue, 2015-10-27 at 10:12 +0100, Stephan Mueller wrote:
>
> >after having discussions with David Howells and David Woodhouse, I don't
> >think we should expose akcipher via AF_ALG at all. I think the akcipher
> >operations for sign/verify/encrypt/decrypt should operate on asymmetric keys
> >in t
Am Dienstag, 27. Oktober 2015, 13:54:30 schrieb Marcel Holtmann:
Hi Marcel,
>Hi Stephan,
>
>> This patch set adds the AF_ALG user space API to externalize the
>> asymmetric cipher API recently added to the kernel crypto API.
>>
>> The patch set is tested with the user space library of libkcapi [
19 matches
Mail list logo
