On 01/25/2015 04:10 PM, Herbert Xu wrote:
> On Sun, Jan 25, 2015 at 08:26:50AM -0800, Tadeusz Struk wrote:
>> > Hi Stephan,
>> > On 01/25/2015 12:58 AM, Stephan Mueller wrote:
>>>> > >> +static int rfc4106_set_key(struct crypto_aead *parent, const u8 *key,
>>>>> > >> > + unsigned int key_len)
>>>>> > >> > {
>>>>> > >> > struct aesni_rfc4106_gcm_ctx *ctx = aesni_rfc4106_gcm_ctx_get(parent);
>>>>> > >> > struct crypto_aead *cryptd_child = cryptd_aead_child(ctx->cryptd_tfm);
>>>>> > >> > + struct aesni_rfc4106_gcm_ctx *child_ctx =
>>>>> > >> > + aesni_rfc4106_gcm_ctx_get(cryptd_child);
>>>>> > >> > + int ret;
>>>>> > >> >
>>>>> > >> > + ret = common_rfc4106_set_key(parent, key, key_len);
>>> > > Shouldn't that one be crypto_aead_setkey, i.e using the regular crypto API
>>> > > instead of internal calls?
>> >
>> > No, I don't think so. I think that would create an infinite loop.
> So why does it work for ablk_helper but not for aead?
Here we have two instances of crypto_aead algorithm, one the
rfc4106(gcm(aes)), whose setkey points to rfc4106_set_key(), and the
internal helper __gcm-aes-aesni (wrapped in by the cryptd interface),
whose setkey points to common_rfc4106_set_key(). If we would call
crypto_aead_setkey() on the parent from rfc4106_set_key() then we would
invoke the same rfc4106_set_key() function. It would be ok to call the
crypto_aead_setkey() on the child, but what's the point?
What we really want to do is to setup the context (authsize and key) for
both the top level rfc4106(gcm(aes)) and the helper __gcm-aes-aesni. We
can do it by calling the internal function directly or by the regular
crypto API crypto_aead_setkey()/set_authsize() on the child, but I don't
see any difference or benefit of it.
Hope that make sense.
Thanks,
Tadeusz
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
