Re: [RFC PATCH] crypto: RSA padding transform

Hi Andrzej, >>> I can see now that with all these padding schemes there will be more buffer >>> copied on top of this, so I wonder if it still make sense. >>> Herbert? >> >> When the padding stuff comes into play, I think the SGL approach avoids >> memcpy() invocations. >> >> For example,

Re: [RFC PATCH] crypto: RSA padding transform

Hi Stephan, On 7 September 2015 at 19:54, Stephan Mueller wrote: > Am Montag, 7. September 2015, 07:31:56 schrieb Tadeusz Struk: >>I can see now that with all these padding schemes there will be more buffer >>copied on top of this, so I wonder if it still make sense.

Re: [RFC PATCH] crypto: RSA padding transform

Hi Andrew, On 09/05/2015 04:00 PM, Andrew Zaborowski wrote: > +static int crypto_akcipher_init(struct crypto_tfm *tfm, u32 type, u32 mask) > +{ > + return 0; > +} > + This is not needed I think. > > +static int pkcs1pad_decrypt_complete(struct akcipher_request *req, int err) > +{ > +

Re: [RFC PATCH] crypto: RSA padding transform

Am Montag, 7. September 2015, 07:11:24 schrieb Tadeusz Struk: Hi Tadeusz, >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,

Re: [RFC PATCH] crypto: RSA padding transform

Am Montag, 7. September 2015, 16:42:42 schrieb Andrzej Zaborowski: Hi Andrzej, > >Specifically I use 1 + prandom_u32_max(255) which should give me >numbers > 0 although it can't be perfectly uniform. Oh, now I see. Thanks for the clarification. And yes, per definition the values cannot be

Re: [RFC PATCH] crypto: RSA padding transform

On 09/06/2015 07:33 AM, Andrzej Zaborowski wrote: > Probably yes, I also read about the decision to use iov buffers, this > will have a bigger effect on code. The more I think about the sgl support the more it looks to me like it wasn't a good idea. It will be copied into a flat buffer somewhere

Re: [RFC PATCH] crypto: RSA padding transform

Hi Tadeusz, On 7 September 2015 at 16:06, Tadeusz Struk wrote: > Hi Andrew, > On 09/05/2015 04:00 PM, Andrew Zaborowski wrote: >> +static int crypto_akcipher_init(struct crypto_tfm *tfm, u32 type, u32 mask) >> +{ >> + return 0; >> +} >> + > > This is not needed I

Re: [RFC PATCH] crypto: RSA padding transform

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

Re: [RFC PATCH] crypto: RSA padding transform

On 6 September 2015 at 23:17, Stephan Mueller wrote: > Am Sonntag, 6. September 2015, 16:33:26 schrieb Andrzej Zaborowski: > > Hi Andrzej, > + for (pos = 2; pos < child_req->dst_len; pos++) + if (dst[pos] == 0x00) + break;

Re: [RFC PATCH] crypto: RSA padding transform

Am Montag, 7. September 2015, 07:31:56 schrieb Tadeusz Struk: Hi Tadeusz, >On 09/06/2015 07:33 AM, Andrzej Zaborowski wrote: >> Probably yes, I also read about the decision to use iov buffers, this >> will have a bigger effect on code. > >The more I think about the sgl support the more it looks

Re: [RFC PATCH] crypto: RSA padding transform

Tadeusz Struk wrote: > > The more I think about the sgl support the more it looks to me like it wasn't > a good idea. It will be copied into a flat buffer somewhere along the way > anyway. > Like in the example below. > > I have that conversion already done, and for SW

Re: [RFC PATCH] crypto: RSA padding transform

Am Sonntag, 6. September 2015, 16:33:26 schrieb Andrzej Zaborowski: Hi Andrzej, >>> + for (pos = 2; pos < child_req->dst_len; pos++) >>> + if (dst[pos] == 0x00) >>> + break; >> >> What happens if the padding has a 0x00 in its pseudo random data? > >The pseudo

Re: [RFC PATCH] crypto: RSA padding transform

Am Sonntag, 6. September 2015, 01:00:29 schrieb Andrew Zaborowski: Hi Andrew, Tadeusz, > This patch adds PKCS#1 v1.5 standard RSA padding as a separate template. > This way an RSA cipher with padding can be obtained by instantiating > "pkcs1pad(rsa-generic)". The reason for adding this is that

Re: [RFC PATCH] crypto: RSA padding transform

Hi Stephan, On 6 September 2015 at 10:34, Stephan Mueller wrote: > Am Sonntag, 6. September 2015, 01:00:29 schrieb Andrew Zaborowski: > Albeit I have nothing to say against the code, but shouldn't we first get the > split of the setkey function implemented? The conversion

[RFC PATCH] crypto: RSA padding transform

This patch adds PKCS#1 v1.5 standard RSA padding as a separate template. This way an RSA cipher with padding can be obtained by instantiating "pkcs1pad(rsa-generic)". The reason for adding this is that RSA is almost never used without this padding (or OAEP) so it will be needed for either