Hi Stephan, On 7 September 2015 at 19:54, Stephan Mueller <smueller@xxxxxxxxxx> 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. >>Herbert? > > When the padding stuff comes into play, I think the SGL approach avoids > memcpy() invocations. > > For example, Andrzej's approach currently is to copy the *entire* source data > into a buffer where the padding is added. > > With SGLs, Andrzej only needs a buffer with the padding (which I would think > could even reside on the stack, provided some bounds checks are done), and > modify the SGL by preprending the padding buffer to the SGL with the source > data. Yes, in the case of the padding schemes, using sgl's would actually save a memcpy both on encrypt/sign and decrypt/verify. Whether it'd actually help I'm not sure -- the number of pointers you need to touch, etc. may add up to around 128/256 bytes of memory access anyway. You couldn't use buffers on stack though unless you only support synchronous underlying RSA implementations. What you could do, for example in sign(), is use a static buffer pre-filled with the pad bytes of specific length. Best regards -- 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
