On Mon, 2014-08-11 at 10:09 +0300, Cristian Stoica wrote: > >> I've tested this patch with AES-CBC-HMAC-SHA1 using the tls module that > >> I've sent recently on Linux mailing list. That module needs rework for > >> Lucky 13 and is a software alternative to the caam driver that does the > >> same thing in hardware. > >> http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg11665.html > > > > Is that supposed to be used with COP_FLAG_AEAD_TLS_TYPE? I believe I had > > added that flag to do exactly the same thing. The implementation is > > pretty old though, and should have the same issue with the cbc padding > > attacks. > > Yes, that kernel patch is used with COP_FLAG_AEAD_TLS_TYPE but there is > a difference from the cryptodev implementation (which I used for > inspiration) in that it registers an algorithm to do the same work. The > reason is that our HW supports AES-CBC-HMAC-SHA1 as a primitive > operation and needs that tls(...) algorithm to advertise the capability.
That makes sense. What I realized after introducing this API, is when speeding that part, the bottleneck becomes the context switches in read()->decrypt() (and encrypt->write). An API that would combine these operations would have provided a significant boost. regards, Nikos _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
