Re: [Cryptodev-linux-devel] Authenticated encryption
On 09/16/2013 10:18 AM, Stoica Cristian-B18196 wrote: >> 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. Not really. Check how examples/aes-sha1.c uses AES with HMAC-SHA1 in a single ioctl. Both keys are passed (as key and mackey). > 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". There are already hooks for TLS in cryptodev-linux (check above). regards, Nikos ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
Re: [Cryptodev-linux-devel] Authenticated encryption
> > > 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
Re: [Cryptodev-linux-devel] Authenticated encryption
> > encrypt then authenticate). This flag is missing in session_op but
> > some of the *BSD distributions added some notes about deprecation of
> > session_op in current form.
>
> Do you have any idea what will replace it? In any case in the current
> approach in linux-cryptodev you don't need a new session op, the old
> one will just do.
[]
For example, in FreeBSD 9 I've found this:
http://fxr.watson.org/fxr/source/opencrypto/cryptodev.h?v=FREEBSD9#L146
145 /* NB: deprecated */
146 struct session_op {
147 u_int32_t cipher; /* ie. CRYPTO_DES_CBC */
148 u_int32_t mac;/* ie. CRYPTO_MD5_HMAC */
149
150 u_int32_t keylen; /* cipher key */
151 caddr_t key;
152 int mackeylen; /* mac key */
153 caddr_t mackey;
154
155 u_int32_t ses;/* returns: session # */
156 };
157
158 struct session2_op {
159 u_int32_t cipher; /* ie. CRYPTO_DES_CBC */
160 u_int32_t mac;/* ie. CRYPTO_MD5_HMAC */
161
162 u_int32_t keylen; /* cipher key */
163 caddr_t key;
164 int mackeylen; /* mac key */
165 caddr_t mackey;
166
167 u_int32_t ses;/* returns: session # */
168 int crid; /* driver id + flags (rw) */
169 int pad[4]; /* for future expansion */
OpenBSD has the original code and NetBSD added a "comp_alg" identifier:
http://fxr.watson.org/fxr/source/crypto/cryptodev.h?v=OPENBSD#L254
http://fxr.watson.org/fxr/source/opencrypto/cryptodev.h?v=NETBSD#L149
149 struct session_op {
150 u_int32_t cipher; /* ie. CRYPTO_DES_CBC */
151 u_int32_t mac;/* ie. CRYPTO_MD5_HMAC */
152 u_int32_t comp_alg; /* ie. CRYPTO_GZIP_COMP */
153
154 u_int32_t keylen; /* cipher key */
155 void * key;
156 int mackeylen; /* mac key */
157 void * mackey;
158
159 u_int32_t ses;/* returns: session # */
160 };
Cristian S.
___
Cryptodev-linux-devel mailing list
Cryptodev-linux-devel@gna.org
https://mail.gna.org/listinfo/cryptodev-linux-devel
Re: [Cryptodev-linux-devel] Authenticated encryption
Hi, On Sun, Sep 15, 2013 at 06:56:14PM +0200, Nikos Mavrogiannopoulos wrote: > On Thu, 12 Sep 2013 13:42:05 + > Stoica Cristian-B18196 wrote: > > > Hi Nikos, > > > > 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? 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. Best wishes, Phil ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
Re: [Cryptodev-linux-devel] Authenticated encryption
On Thu, 12 Sep 2013 13:42:05 + Stoica Cristian-B18196 wrote: > Hi Nikos, > > 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? I believe that you can fit that in to the current authcrypt API, possibly by adding an additional flag to the COP_FLAG_AEAD flags. > One solution would be to add new algorithms in cryptodev_crypto_op_t > and then adapt crypto_create_session to ask the kernel for a certain > algorithm (like authenc(hmac(sha1),aes-cbc)). There are some issues > here, one with the proliferation of non-standard algorithms and > another with the way those algorithms would be handled by the kernel > (order of applying authentication and encryption). Another solution > may be to set both the crypto and the mac algorithm in the session > (the same as in tests/cipher-aead.c) with an added new flag saying > how the algorithms would be combined (authenticate then encrypt, > encrypt then authenticate). This flag is missing in session_op but > some of the *BSD distributions added some notes about deprecation of > session_op in current form. Do you have any idea what will replace it? In any case in the current approach in linux-cryptodev you don't need a new session op, the old one will just do. About the proliferation of ciphers, I also don't think that this is a problem. I don't expect all AEAD modes to be in actual use, and in any case the integer range is quite large. regards, Nikos ___ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
