[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b1ce2519-df59-58c5-a1e4-c795afce3551@intel.com>
Date: Mon, 16 May 2016 07:23:48 -0700
From: Tadeusz Struk <tadeusz.struk@...el.com>
To: Mat Martineau <mathew.j.martineau@...ux.intel.com>
Cc: dhowells@...hat.com, herbert@...dor.apana.org.au,
smueller@...onox.de, linux-api@...r.kernel.org,
marcel@...tmann.org, linux-kernel@...r.kernel.org,
keyrings@...r.kernel.org, linux-crypto@...r.kernel.org,
dwmw2@...radead.org, davem@...emloft.net
Subject: Re: [PATCH RESEND v5 6/6] crypto: AF_ALG - add support for key_id
Hi Mat,
On 05/13/2016 04:32 PM, Mat Martineau wrote:
>
>> + params.data_len = req->src_len;
>> + params.enc_len = req->dst_len;
Thanks for info. I have sent an update for this.
>
> The params member names have changed (now in_len and out_len).
>> + ret = encrypt_blob(¶ms, in, out);
>
> The encrypt function for the key can now be called with params.key->type->asym_eds_op(). This also allows you to factor out the duplication in asym_key_encrypt, asym_key_decrypt, and asym_key_sign. See keyctl_pkey_e_d_s() in keyctl_pkey.c
>
>> +static int asym_key_verify(const struct key *key, struct akcipher_request *req)
> ...
>> + ret = verify_signature(key, NULL, &sig);
>
> key->type->asym_verify_signature() is available as well.
Since these operation will be triggered from userspace I think it's better to use the
official interface as defined in crypto/public_key.h instead of direct calls.
Some operation may not be implemented for a given key type and the official interface
performs necessary checks.
Thanks,
--
TS
Powered by blists - more mailing lists