From: Tadeusz Struk <tadeusz.struk@intel.com>
To: Stephan Mueller <smueller@chronox.de>,
Andrew Zaborowski <andrew.zaborowski@intel.com>
Cc: linux-crypto@vger.kernel.org
Subject: Re: [RFC PATCH] crypto: RSA padding transform
Date: Mon, 7 Sep 2015 07:11:24 -0700 [thread overview]
Message-ID: <55ED9B0C.3020905@intel.com> (raw)
In-Reply-To: <35165141.6IIWPIRvUD@myon.chronox.de>
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.
next prev parent reply other threads:[~2015-09-07 14:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-05 23:00 [RFC PATCH] crypto: RSA padding transform Andrew Zaborowski
2015-09-06 8:34 ` Stephan Mueller
2015-09-06 14:33 ` Andrzej Zaborowski
2015-09-06 21:17 ` Stephan Mueller
2015-09-07 14:42 ` Andrzej Zaborowski
2015-09-07 15:10 ` Stephan Mueller
2015-09-07 14:31 ` Tadeusz Struk
2015-09-07 17:54 ` Stephan Mueller
2015-09-08 16:09 ` Andrzej Zaborowski
2015-10-30 8:35 ` Marcel Holtmann
2015-09-08 1:07 ` Herbert Xu
2015-09-07 14:11 ` Tadeusz Struk [this message]
2015-09-07 15:07 ` Stephan Mueller
2015-09-07 14:06 ` Tadeusz Struk
2015-09-07 14:38 ` Andrzej Zaborowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55ED9B0C.3020905@intel.com \
--to=tadeusz.struk@intel.com \
--cc=andrew.zaborowski@intel.com \
--cc=linux-crypto@vger.kernel.org \
--cc=smueller@chronox.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.