On 09/06/2015 01:34 AM, Stephan Mueller wrote: >> +static int pkcs1pad_setkey(struct crypto_akcipher *tfm, const void *key, >> > + unsigned int keylen) > Albeit I have nothing to say against the code, but shouldn't we first get the > split of the setkey function implemented? The conversion work will increase > more and more we merge code that uses that API that was decided to be > revamped. > > Tadeusz, what do you think? It would make it easier for me if this could wait until the split is done. >> + akcipher_request_set_crypt(req, NULL, NULL, 0, 0); >> > + if (crypto_akcipher_encrypt(req) != -EOVERFLOW) >> > + err = -EINVAL; > I had a chat with Tadesusz already on this code which I need for the > algif_akcipher code too (and there I need this check more often as user space > may simply change the key under my feet). I feel that it is a waste of CPU > cycles to set up a fake encryption request just to get the data length which > is based on the used key. > > The value we obtain here is simply a check of the key length. Thus, I would > think that we should have a separate akcipher API call for this instead of > requiring the caller to allocate a fake request context. > > Tadeusz, are you working on that code or shall I have a look? I wasn't planning to add this, but yes, I think it's a good idea. I'll add it. -- 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
