Re: [PATCH v8 3/4] crypto: AF_ALG -- add asymmetric cipher

[Tudor Ambarus <tudor.ambarus@microchip.com>]

On 08/21/2017 11:55 AM, Tudor Ambarus wrote:
> Hi, Stephan,
> 
>>>> +static int akcipher_setprivkey(void *private, const u8 *key,
>>>> +                   unsigned int keylen)
>>>> +{
>>>> +    struct akcipher_tfm *tfm = private;
>>>> +    struct crypto_akcipher *akcipher = tfm->akcipher;
>>>> +    int err;
>>>> +
>>>> +    err = crypto_akcipher_set_priv_key(akcipher, key, keylen);
>>>> +    tfm->has_key = !err;
>>>> +
>>>> +    /* Return the maximum size of the akcipher operation. */
>>>> +    if (!err)
>>>> +        err = crypto_akcipher_maxsize(akcipher);
>>>
>>> crypto subsystem returns zero when setkey is successful and introduces
>>> a new function for determining the maxsize. Should we comply with that?
>>
>> The idea is that only when the the setting of the priv key fails, it 
>> returns
>> the size of the expected privkey.
>>
>> Which new function are you referring to?
> 
> I was referring to crypto_akcipher_maxsize. When
> crypto_akcipher_set_priv_key fails, you are overwriting it's return
> value with the value of crypto_akcipher_maxsize, hiding the cause of
> the error.

Oops, I missed the negation. When crypto_akcipher_set_priv_key succeeds
you return the akcipher_maxsize. Not a bad idea, you save few cpu
cycles.

> 
> crypto akcipher uses a dedicated function for determining the length of
> the output buffer, crypto_akcipher_maxsize. Should we add a new function
> pointer in struct af_alg_type that returns the maxsize?

Your API is different from crypto's akcipher. Should we make them
identical?

Cheers,
ta