> > > I'm looking at a possibility to add support for composite algorithms > > > in cryptodev. Basically this means support for algorithms that do for > > > example AES-CBC and HMAC(SHA1) in one call on platforms that support > > > it. > > > > Hello Cristian, > > Currently we have something similar with the AUTHCRYPT ioctl that > > does authenticated encryption in a single kernel call. However, I > > believe that you mean something like AUTHCRYPT that is done not only > > in a single kernel call, but also in a hardware call as well? [] Yes, hw offload through a single ioctl is the goal.
> > AFAIK, AEAD is supported by a few crypto engines and their drivers. So > simply using the AEAD interface of cryptodev-linux should suffice if > appropriate hardware is present. [] Authenticated encryption *dedicated schemes* (algorithms like AES-CCM, AES-GCM) require only one key. This is what cryptodev is giving to the kernel through cryptodev_cipher_init -> crypto_aead_setkey. *Generic composition* schemes require two keys, one for crypto and one for keyed authentication (eg. AES-CBC + HMAC(SHA1)). This is what the kernel expects through authenc.c:crypto_authenc_setkey. I believe these schemes don't work now through cryptodev since the kernel always receives just a single key (the crypto one) from cryptodev. There is a second issue with what authenc does in the kernel. Since it was designed for IPsec, the composition scheme won't work for example with TLS and new algorithms may be required in the kernel to accommodate "authenticate then encrypt". Thus, the aead interface can be used if there is also a convention on what users are giving to cryptodev as algorithms and what the kernel will execute. At least that's my understanding of the whole issue so far. Cristian S. _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
