lkml.org 
[lkml]   [2016]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v2] crypto: AF_ALG - add support for keys/asymmetric-type
From
Date
Hi David, David and Marcel,
On 12/26/2015 07:50 AM, Tadeusz Struk wrote:
> From: Tadeusz Struk <tadeusz.struk@intel.com>
>
> Created on top of patchset from Stephan Mueller <smueller@chronox.de>
> https://patchwork.kernel.org/patch/7877921/
> https://patchwork.kernel.org/patch/7877971/
> https://patchwork.kernel.org/patch/7877961/
>
> This patch adds support for asymmetric key type to AF_ALG.
> It will work as follows: A new PF_ALG socket options will be
> added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely
> ALG_SET_PUBKEY_ID and ALG_SET_KEY_ID for setting public and
> private keys respectively. When these new options will be used
> the user instead of providing the key material, will provide a
> key id and the key itself will be obtained from kernel keyring
> subsystem. The user will use the standard tools (keyctl tool
> or the keyctl syscall) for key instantiation and to obtain the
> key id. The key id can also be obtained by reading the
> /proc/keys file.
>
> When a key will be found, the request_key() function will
> return a requested key. Next the asymmetric key subtype will be
> used to obtain the public_key, which can be either a public key
> or a private key from the cryptographic point of view, and the
> key payload will be passed to the akcipher pf_alg subtype.
> Pf_alg code will then call crypto API functions, either the
> crypto_akcipher_set_priv_key or the crypto_akcipher_set_pub_key,
> depending on the used option. Subsequently the asymmetric key
> will be freed and return code returned back to the user.
>
> Currently the interface will be restricted only to asymmetric
> ciphers, but it can be extended later to work with symmetric
> ciphers if required.
>
> The assumption is that access rights for a given user will be
> verified by the key subsystem so the pf_alg interface can call
> the request_key() without checking if the user has appropriate
> rights (Please verify this assumption).
>
> Changes in v2:
> Separate logic for setkey and setkey_id into two separate
> functions as proposed by Stephan.
>
> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> ---
> crypto/af_alg.c | 49 +++++++++++++++++++++++++++++++++++++++----
> include/uapi/linux/if_alg.h | 2 ++
> 2 files changed, 47 insertions(+), 4 deletions(-)

Do you have any comments on this?
Based on your feedback after Stephan sent the v2 algif_akcipher patches
the conclusion was that having both setkey and setkey_id will be acceptable.
This is exactly what this patch does, so will the algif_akcipher patches
with this one on top work for you?
Thanks,
--
TS

\
 
 \ /
  Last update: 2016-01-12 07:41    [W:0.040 / U:0.344 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site