[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <557F83DF.2090003@intel.com>
Date: Mon, 15 Jun 2015 19:03:11 -0700
From: Tadeusz Struk <tadeusz.struk@...el.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
CC: linux-kernel@...r.kernel.org, keescook@...omium.org,
jwboyer@...hat.com, smueller@...onox.de, richard@....at,
steved@...hat.com, qat-linux@...el.com, dhowells@...hat.com,
linux-crypto@...r.kernel.org, james.l.morris@...cle.com,
jkosina@...e.cz, zohar@...ux.vnet.ibm.com, davem@...emloft.net,
vgoyal@...hat.com
Subject: Re: [PATCH RFC v5 2/4] crypto: add PKE API
On 06/15/2015 05:05 PM, Herbert Xu wrote:
>> > + * @setkey: Function invokes the algorithm specific set key function, which
>> > + * knows how to decode and interpret the BER encoded key
> We should split this into two functions: setpubkey and setprivkey.
>
The two functions will be almost identical. We can do it this way if we want to check
if all the required elements of the key are provided. Currently I'm checking this in the
actual operation.
>> > + *
>> > + * @reqsize: Request context size required by algorithm implementation
>> > + * @base: Common crypto API algorithm data structure
>> > + */
>> > +struct akcipher_alg {
>> > + int (*sign)(struct akcipher_request *req);
>> > + int (*verify)(struct akcipher_request *req);
>> > + int (*encrypt)(struct akcipher_request *req);
>> > + int (*decrypt)(struct akcipher_request *req);
>> > + int (*maxsize)(struct crypto_akcipher *tfm);
> Hmm, we could actually get rid of maxsize by just having each
> function check the dst_len and if it is insufficient write the
> required length in it and then return an error.
Can do it that way too.
Thanks for your feedback. I will send v6 soon.
Thanks
T
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists