Re: [Cryptodev-linux-devel] [PATCH 3/3] add support for composite aead keys
Hi Nikos, On 19.08.2014 07:52, Nikos Mavrogiannopoulos wrote: > On Mon, 2014-08-11 at 10:09 +0300, Cristian Stoica wrote: > >> 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. The speed-up we get with the current API is pretty good but we know is due only to hardware acceleration. We're doing some profiling and for several reasons we wanted keep API changes to minimum. Yet if we see improvements in this area we'll send patches for review. Thanks, Cristian S. ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
Re: [Cryptodev-linux-devel] [PATCH 3/3] add support for composite aead keys
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
Re: [Cryptodev-linux-devel] [PATCH 3/3] add support for composite aead keys
Hi Nikos, On 10.08.2014 00:06, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-08-06 at 14:23 +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. Cristian S. ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
Re: [Cryptodev-linux-devel] [PATCH 3/3] add support for composite aead keys
On Wed, 2014-08-06 at 14:23 +0300, Cristian Stoica wrote: > Hi Nikos, > > On 06.08.2014 13:58, Nikos Mavrogiannopoulos wrote: > > On Fri, May 30, 2014 at 12:59 PM, Cristian Stoica > > wrote: > >> - block and stream ciphers have their keys copied from userspace > >> just like before > >> - for aead composite ciphers, the cipher and hmac keys are > >> combined into a single key > > > > Hello Christian, > > Do you have some test case on that? Which composite AEAD ciphers are > > being supported? > > 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. regards, Nikos ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
Re: [Cryptodev-linux-devel] [PATCH 3/3] add support for composite aead keys
Hi Nikos, On 06.08.2014 13:58, Nikos Mavrogiannopoulos wrote: > On Fri, May 30, 2014 at 12:59 PM, Cristian Stoica > wrote: >> - block and stream ciphers have their keys copied from userspace >> just like before >> - for aead composite ciphers, the cipher and hmac keys are >> combined into a single key > > Hello Christian, > Do you have some test case on that? Which composite AEAD ciphers are > being supported? 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 Cristian S. ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
Re: [Cryptodev-linux-devel] [PATCH 3/3] add support for composite aead keys
On Fri, May 30, 2014 at 12:59 PM, Cristian Stoica wrote: > - block and stream ciphers have their keys copied from userspace > just like before > - for aead composite ciphers, the cipher and hmac keys are > combined into a single key Hello Christian, Do you have some test case on that? Which composite AEAD ciphers are being supported? regards, Nikos ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
