On 12/12/2013 5:30 PM, Nikos Mavrogiannopoulos wrote:
On Thu, Dec 12, 2013 at 3:35 PM, Horia Geantă
<horia.gea...@freescale.com> wrote:
Hello,
This does not compile. You seem to use dst_len that isn't there in the
definitions of these structures.
Sorry for that. There are a few more patches that need to be upstreamed.
We internally modified the interface (struct crypt_auth_op), so that user
provides both source buffer length (len) and destination buffer length
(dst_len).
Is this acceptable?
It sounds reasonable for future extensibility, but I'm curious why did
you need that? In existing AEAD cipher there is no padding involved so
the destination size is known.
This has to do with adding TLS record offloading support in kernel.
The kernel patches haven't been sent out for review yet.
I am sending the cryptodev patchset as [RFC].
Note that patch 9/9 add support for composite TLS(SHA1,AES) algorithm
offload depends on the kernel crypto API changes (which might not be
accepted as is). More exactly, the template name
"tls10(hmac(sha1),cbc(aes))" might change.
Patch 7/9 adds the dst_len.
Without it, there are issues with dst len in __crypto_auth_run_zc for
the case (caop->flags & COP_FLAG_AEAD_TLS_TYPE && ses_ptr->cdata.aead !=
0). We fall in this case when offloading "one-shot" TLS (CIOCAUTHCRYPT)
for stitched (hmac(sha1),aes(cbc)).
For now, we are performing tests using OpenSSL 1.0.1e, with modified
cryptodev-engine, see "add support for TLS algorithms offload" patch.
Regards,
Horia
_______________________________________________
Cryptodev-linux-devel mailing list
Cryptodev-linux-devel@gna.org
https://mail.gna.org/listinfo/cryptodev-linux-devel
