Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

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 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 to support the use 
case where the software wants to be in control (just take OpenSSL as the 
simple example where you can add an engine for the Linux kernel backed RSA 
operation).

Note, the goal with AF_ALG is simply to expose asymmetric hardware support to 
user space for unspecified use cases to make user space faster.
>
>For a key which *happens* to be in software, the key subsystem may end
>up *using* akcipher behind the scenes. But the API we expose to
>userspace cannot simply be based on akcipher.

So, how do you propose that would work? Based on what I understand the 
suggested logic flow for a simple OpenSSL-like approach would be:

1. OpenSSL opens the interface with the kernel key subsystem and sends the 
pub/priv key along
 
2. the key subsystem hooks the key in

3. the key subsystem sees that there is a simple RSA operation to be made

4. the key subsystem initiates an akcipher operation and sends the keys along

5. the akcipher returns the cipher result to the key subsystem

6. the key subsystem sends the data to user space

Currently I fail to understand why that key subsystem would help me in that 
common use case (note, I totally understand to use the key subsystem when you 
have some key management schema in place).

Also, I fail to see that this logic flow would be fast to warrant a detour 
from user land into kernel land for an RSA operation.

Thanks
Stephan
--
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

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Tadeusz Struk]

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 first place. With akcipher you are pretty much bound to public and 
> private keys and the key is the important part and not the akcipher itself. 
> Especially since we want to support private keys in hardware (like TPM for 
> example).
> 
> It seems more appropriate to use keyctl to derive the symmetric session key 
> from your asymmetric key. And then use the symmetric session key id with 
> skcipher via AF_ALG. Especially once symmetric key type has been introduced 
> this seems to be trivial then.
> 
> I am not really in favor of having two userspace facing APIs for asymmetric 
> cipher usage. And we need to have an API that is capable to work with 
> hardware keys.

The main use case for algif_akcipher will be to allow a web server, which needs 
to handle
tens of thousand TLS handshakes per second, to offload the RSA operation to a 
HW accelerator.
Do you think we can use keyctl for this?
Thanks,
T
--
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

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[David Woodhouse]

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 to support the 
> use 
> case where the software wants to be in control (just take OpenSSL as the 
> simple example where you can add an engine for the Linux kernel backed RSA 
> operation).

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 libraries and applications accept PKCS#11 URIs
referring to keys in hardware as well as filenames.

I am violently opposed to exposing an API from the kernel which makes
that *same* fundamental mistake, and ties its users to using *only*
software keys.

FROM THE BEGINNING, users of this new API should be able to cope with
the fact that they might not *have* the key material, and that they
might simply be referring to a key which exists elsewhere. Such as in
the TPM, or within an SGX software enclave.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

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 libraries and applications accept PKCS#11 URIs
>referring to keys in hardware as well as filenames.
>
>I am violently opposed to exposing an API from the kernel which makes
>that *same* fundamental mistake, and ties its users to using *only*
>software keys.
>
>FROM THE BEGINNING, users of this new API should be able to cope with
>the fact that they might not *have* the key material, and that they
>might simply be referring to a key which exists elsewhere. Such as in
>the TPM, or within an SGX software enclave.

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 process for such a web server shall really 
work?


Ciao
Stephan
--
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

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

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 majority of configs.
> > 
> > Can you please elaborate how the process for such a web server shall
> > really
> > work?
> 
> 1. Create a kernel-side key.
> 2. Use it.
> 
> That may require adding an API similar to the one you're proposing, but
> working with kernel keys instead of directly with akcipher. Or perhaps
> the key subsystem can already offer what you need in userspace. David?

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 keyring?

However, for the actual data shoveling, AF_ALG should still be used?


-- 
Ciao
Stephan
--
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

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Marcel Holtmann]

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 process for such a web server shall
>>> really
>>> work?
>> 
>> 1. Create a kernel-side key.
>> 2. Use it.
>> 
>> That may require adding an API similar to the one you're proposing, but
>> working with kernel keys instead of directly with akcipher. Or perhaps
>> the key subsystem can already offer what you need in userspace. David?
> 
> Ohh, I see. So, you are saying that there should not be a setpub/privkey for 
> the akcipher AF_ALG interface?!

I tested support for adding ALG_SET_KEY_ID which takes the 32-bit key serial 
and then using AF_ALG with an skcipher. That works so far so fine. For making 
this super clean and get it upstream, it needs a symmetric key type (which is 
planned to be added by David). I can post my current patch as RFC since it is 
dead simple actually.

> If somebody wants to use akcipher, he shall set the key via the keyring and 
> akcipher shall obtain it from the keyring?
> 
> However, for the actual data shoveling, AF_ALG should still be used?

There is no massive data shoveling by an akcipher. All data shoveling for TLS 
is done via the symmetric session key that is negotiated. Actually with 
asymmetric ciphers, your keys will be normally larger than your clear text 
anyway.

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 for the data shoveling.

However that all said, the keys should never leave the kernel. Neither the 
private key nor the session key. There is no point in sending keys through 
userspace. We actually do not want this at all. That is especially important if 
your actual private/public key pair is in hardware. So maybe your RSA 
accelerator might expose secure storage for the keys. Loading them over and 
over again from userspace makes no sense.

As David mentioned, we need to take a deep look at what the userspace API for 
asymmetric cipher suites (and we also have needs for ECDH etc. and not just 
RSA) should look like. Just exposing akcipher via AF_ALG is premature. If we 
expose it now, it is not an API that we can take back. Having two userspace 
APIs for the exactly the same functionality is a bad thing. Especially if one 
is limited to software only keys.

We also need to look at the larger picture here. And that is TLS support in the 
kernel. Potentially via AF_KCM or something similar.

And with TLS in mind, we actually do want to just load the whole X.509 
certificate into the key subsystem. It will then allow you retrieve the key id, 
validate the certificate and use the key. Current kernels already support this 
kind of functionality and we want to enable this and extend it. Having random 
pieces in userspace and/or kernel space to extract keys from the containers is 
a pretty bad idea. We really want this centralized. Here the same goal applies, 
to not have multiple userspace APIs doing the same thing.

Regards

Marcel

--
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

Re: kernel tainted while exporting shash context using af_alg interface

[Stephan Mueller]

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 approach is correct after all. I was 
able to reproduce the crash by simply adding more accept calls to my test 
code. And I can confirm that your patch works, for hashes.

*BUT* it does NOT work for HMAC as the key is set on the TFM and the 
subsequent accepts do not transport the key. Albeit your code prevents the 
kernel from crashing, the HMAC calculation will be done with an empty key as 
the setkey operation does not reach the TFM handle in the subordinate accept() 
call.

So, I would think that the second accept is simply broken, for HMAC at least.

Herbert, what is the purpose of that subordinate accept that is implemented 
with hash_accept? As this is broken for HMACs, should it be removed entirely?

-- 
Ciao
Stephan
--
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

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

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, he shall set the key via the keyring
> > and
> > akcipher shall obtain it from the keyring?
> > 
> > However, for the actual data shoveling, AF_ALG should still be used?
> 
> That might seem ideal, but Herbert doesn't want that — he wants
> akcipher to work *only* with its own internal keys, not with keys from
> the kernel's key subsystem.
> 
> David has patches (not upstream yet; used for testing) which expose a
> verify operation for kernel keys through sys_keyctl(). Adding the other
> three operations would be feasible.
> 
> Perhaps if we *really* want this to appear through AF_ALG, the key
> subsystem could register its own RSA (and other) implementation(s) with
> the crypto subsystem. Then we could find some way that we can pass the
> key_serial_t through alg_setkey() instead of the actual key data
> without it (or Herbert) noticing that's what we're doing. But... ick.
> And I don't think we can select algorithms based on the actual key
> rather than the type. We should do it properly, if at all. And define
> the API as taking key IDs instead of having it be a nasty special-case
> hack for a specific (but really, very generic) algorithm provider.

First of all, I personally would not insist on an AF_ALG for pure akcipher 
externalization. Integrating it with the key subsystem looks like a fine idea.

But that would imply that we tie the crypto API quite hard with the key 
retention system which I guess may not be warranted.

Note, I was playing with the idea of using the key retention system for the 
kernel crypto API myself (hence also my patch to add key wrapping support 
which has its roots there).

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.

But I agree that when having both and the user wants proper key management, 
the key system should be used. But isn't that already a policy decision of the 
user/administrator? IIRC, the kernel should not hard-wire policies that may or 
may not be wanted by user space. Hence, the decision about connecting both 
systems should rest in user space. And the kernel should support a joint 
operation of both.


-- 
Ciao
Stephan
--
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

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[Stephan Mueller]

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. That
> session key can then be used with AF_ALG and skcipher for the data
> shoveling.
> 
> However that all said, the keys should never leave the kernel. Neither the

I personally do not fully agree here. For our day-to-day desktops and servers 
I would fully and completely agree. But I see other use cases of Linux in 
routers or other embedded systems where there may be other checks and balances 
in place where this hard demand is not warranted.

Thus, I feel that this is a policy decision to be made in user space (see my 
other email -- please answer on that topic there to keep a single thread).

> private key nor the session key. There is no point in sending keys through
> userspace. We actually do not want this at all. That is especially
> important if your actual private/public key pair is in hardware. So maybe
> your RSA accelerator might expose secure storage for the keys. Loading them
> over and over again from userspace makes no sense.
> 
> As David mentioned, we need to take a deep look at what the userspace API
> for asymmetric cipher suites (and we also have needs for ECDH etc. and not
> just RSA) should look like. Just exposing akcipher via AF_ALG is premature.
> If we expose it now, it is not an API that we can take back. Having two
> userspace APIs for the exactly the same functionality is a bad thing.
> Especially if one is limited to software only keys.

Do not get me wrong, my patch is shall be there for all to comment. I have no 
issues when we find a better solution. And I also do not like multiple 
interfaces that would not be needed if we would have thought better.
> 
> We also need to look at the larger picture here. And that is TLS support in
> the kernel. Potentially via AF_KCM or something similar.

With all due respect, I would object here. When we say yes to TLS (even if it 
is parts of TLS up to the point where the KDF happens), we invite all higher 
level crypto implementations: IKE, SNMP, SSH -- I would not want to go down 
that path that started by simply supporting accelerated asymmetric ciphers.

Look at user space crypto libs: where is the most fuzz happening? Not in the 
cipher implementations, but in the network protocols.


-- 
Ciao
Stephan
--
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

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[David Woodhouse]

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 that we will *always* have the actual key material
> > in a file — and making libraries and applications accept PKCS#11 URIs
> > referring to keys in hardware as well as filenames.
> > 
> > I am violently opposed to exposing an API from the kernel which makes
> > that *same* fundamental mistake, and ties its users to using *only*
> > software keys.
> > 
> > FROM THE BEGINNING, users of this new API should be able to cope with
> > the fact that they might not *have* the key material, and that they
> > might simply be referring to a key which exists elsewhere. Such as in
> > the TPM, or within an SGX software enclave.
> 
> 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 process for such a web server shall really 
> work?

1. Create a kernel-side key.
2. Use it.

That may require adding an API similar to the one you're proposing, but
working with kernel keys instead of directly with akcipher. Or perhaps
the key subsystem can already offer what you need in userspace. David?

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature

Re: kernel tainted while exporting shash context using af_alg interface

[Stephan Mueller]

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

It seems your user space does something like:

socket()
fd = bind()
fd1 = accept(fd)
fd2 = accept(fd1)
fd3 = accept(fd2)
...

That is an error in the user space code. The correct way would be like the 
code in [1] with all the lines until the line 553 (the code afterwards is for 
vmsplice).

So, the code goes like that:

tfmfd = socket()
bind(tfmfd)
opfd = accept(tfmfd);

>From now on, you use opfd for all sendmsg/recvmsg operations.


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.

I would rather think the following patch should be added to prevent the oops. 
At least for me, multiple accepts does not crash the kernel. Can you please 
test whether this patch ensures you kernel stays sane?

diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 1396ad0..785df23 100644
--- a/crypto/algif_hash.c
+++ b/crypto/algif_hash.c
@@ -183,6 +183,9 @@ static int hash_accept(struct socket *sock, struct socket 
*newsock, int flags)
struct hash_ctx *ctx2;
int err;
 
+   if (!ctx->more)
+   return -EINVAL;
+
err = crypto_ahash_export(req, state);
if (err)
return err;


[1] 
https://github.com/smuellerDD/libkcapi/blob/master/lib/kcapi-kernel-if.c#L534


-- 
Ciao
Stephan
--
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

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[David Woodhouse]

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 keyring?
> 
> However, for the actual data shoveling, AF_ALG should still be used?

That might seem ideal, but Herbert doesn't want that — he wants
akcipher to work *only* with its own internal keys, not with keys from
the kernel's key subsystem.

David has patches (not upstream yet; used for testing) which expose a
verify operation for kernel keys through sys_keyctl(). Adding the other
three operations would be feasible.

Perhaps if we *really* want this to appear through AF_ALG, the key
subsystem could register its own RSA (and other) implementation(s) with
the crypto subsystem. Then we could find some way that we can pass the
key_serial_t through alg_setkey() instead of the actual key data
without it (or Herbert) noticing that's what we're doing. But... ick.
And I don't think we can select algorithms based on the actual key
rather than the type. We should do it properly, if at all. And define
the API as taking key IDs instead of having it be a nasty special-case
hack for a specific (but really, very generic) algorithm provider.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature

[PATCH] crypto: Add support for ALG_SET_KEY_ID for skcipher

[Marcel Holtmann]

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 to the keys subsystem and might need to be exposed to usage by
the crypto subystem first. This is just a RFC and not for merging !!!

Signed-off-by: Marcel Holtmann 
---
 crypto/af_alg.c | 14 ++
 crypto/algif_skcipher.c | 25 +
 include/crypto/if_alg.h |  2 ++
 include/uapi/linux/if_alg.h |  1 +
 4 files changed, 42 insertions(+)

diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index a8e7aa3e257b..48ddbb4063aa 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -203,6 +203,7 @@ static int alg_setsockopt(struct socket *sock, int level, 
int optname,
struct alg_sock *ask = alg_sk(sk);
const struct af_alg_type *type;
int err = -ENOPROTOOPT;
+   key_serial_t keyid;
 
lock_sock(sk);
type = ask->type;
@@ -225,6 +226,19 @@ static int alg_setsockopt(struct socket *sock, int level, 
int optname,
if (!type->setauthsize)
goto unlock;
err = type->setauthsize(ask->private, optlen);
+   break;
+   case ALG_SET_KEY_ID:
+   if (sock->state == SS_CONNECTED)
+   goto unlock;
+   if (!type->setkeyid)
+   goto unlock;
+
+   err = -EFAULT;
+   if (get_user(keyid, (key_serial_t __user *) optval))
+   goto unlock;
+
+   err = type->setkeyid(ask->private, keyid);
+   break;
}
 
 unlock:
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 945075292bc9..5dfae3cb6e20 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -22,6 +22,8 @@
 #include 
 #include 
 #include 
+#include 
+#include "../security/keys/internal.h"
 
 struct skcipher_sg_list {
struct list_head list;
@@ -764,6 +766,28 @@ static int skcipher_setkey(void *private, const u8 *key, 
unsigned int keylen)
return crypto_ablkcipher_setkey(private, key, keylen);
 }
 
+static int skcipher_setkeyid(void *private, key_serial_t id)
+{
+   key_ref_t key_ref;
+   int err = -EPROTOTYPE;
+
+   key_ref = lookup_user_key(id, 0, KEY_NEED_READ);
+   if (IS_ERR(key_ref))
+   return PTR_ERR(key_ref);
+
+   if (key_ref_to_ptr(key_ref)->type == _type_user) {
+   struct user_key_payload *upayload;
+
+   upayload = rcu_dereference_key(key_ref_to_ptr(key_ref));
+
+   err = crypto_ablkcipher_setkey(private, upayload->data,
+  upayload->datalen);
+   }
+
+   key_ref_put(key_ref);
+   return err;
+}
+
 static void skcipher_wait(struct sock *sk)
 {
struct alg_sock *ask = alg_sk(sk);
@@ -832,6 +856,7 @@ static const struct af_alg_type algif_type_skcipher = {
.bind   =   skcipher_bind,
.release=   skcipher_release,
.setkey =   skcipher_setkey,
+   .setkeyid   =   skcipher_setkeyid,
.accept =   skcipher_accept_parent,
.ops=   _skcipher_ops,
.name   =   "skcipher",
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index 018afb264ac2..f71d88162326 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -51,6 +52,7 @@ struct af_alg_type {
int (*setkey)(void *private, const u8 *key, unsigned int keylen);
int (*accept)(void *private, struct sock *sk);
int (*setauthsize)(void *private, unsigned int authsize);
+   int (*setkeyid)(void *private, key_serial_t id);
 
struct proto_ops *ops;
struct module *owner;
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index d81dcca5bdd7..28cdc05695c0 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -34,6 +34,7 @@ struct af_alg_iv {
 #define ALG_SET_OP 3
 #define ALG_SET_AEAD_ASSOCLEN  4
 #define ALG_SET_AEAD_AUTHSIZE  5
+#define ALG_SET_KEY_ID 6
 
 /* Operations */
 #define ALG_OP_DECRYPT 0
-- 
2.4.3

--
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

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

[David Woodhouse]

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, let people load keys directly without having to instantiate keys
and then reference them. My point is that only an API which permits
*both* models is acceptable. Otherwise, people build bogus assumptions
all the way up the stack.

Having both ALG_SET_KEY and ALG_SET_KEY_ID in parallel seems ideal.

-- 
dwmw2




smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH] crypto: Add support for ALG_SET_KEY_ID for skcipher

[Marcel Holtmann]

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_user_key() is currently
>> private to the keys subsystem and might need to be exposed to usage by
>> the crypto subystem first. This is just a RFC and not for merging !!!
> 
> First, thanks for sharing.
> 
> Albeit I have not had a deep look into that code, but I think your patch is 
> incomplete: you have to tie the kernel crypto API to the key retention system 
> in the Kconfig.
> 
> I guess that is one of the concerns that Herbert may have? See my other email 
> regarding this.

of course we have to tie this together. And I need to deal with Kconfig once we 
have symmetric key type support.

However I am not too much worried since reality is that the keys subsystem is 
pretty much mandatory if you use module signing (or firmware signing in the 
future). And with moving the keys subsystem to use akcipher and consolidate on 
a single RSA implementation in the kernel, I am not convinced that this is 
actually a real problem.

Also it is perfectly valid to return EOPNOTSUPP when using ALG_SET_KEY_ID and 
you do not have the keys subsystem configured. I do not see that as a problem.

Regards

Marcel

--
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