Re: [Ocf-linux-users] AEAD support in OCF

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi David,

I do agree that Linux is giving async crypto support for many algorithms including aead ones. However, for hardware accelerator the advantage that OCF brings in is that of portability. We expect to easily port the same driver to other platforms ones we have it working for one platform, Linux in this particular case. So, I believe it'll be a good idea to keep the OCF in sync with the newer developments in the crypto world. 

I'll make a proper proposal in the coming week to you about the modifications we would need in the data structures. Let's take it forward from there. Does it sound good?

Thanks and regards,
Gandhar Gokhale

-----Original Message-----
From: David McCullough [mailto:Dav...@se...] 
Sent: Friday, 29 January, 2010 7:46 PM
To: Gokhale, Gandhar
Cc: ocf...@li...
Subject: Re: [Ocf-linux-users] AEAD support in OCF

Jivin Gokhale, Gandhar lays it down ...
> Hi David,
> Thanks for pointing out aead-aes-cbc-hmac-sha. However, I could not get a ratified standard for this. I could get only an expired draft of this. So, this may not be the perfect example to look at. However, it'll be great if you could point me to an example OCF driver that has a support for aead-aes-cbc-hmac-sha. 
> I see that we need to have a few more fields (maybe union) in the cryptoini and/or cryptodesc structure to support the AAD, the nonce or maybe IV and salt separately. This will be needed even in case of aead-aes-cbc-hmac-sha. Details need to be finalized after carefully looking into all the AEAD algorithms available so far. If there is an existing aead-aes-cbc-hmac-sha OCF driver we can see how it uses the data structures as an example.

Currently, one way to do a combination of aes-cbc/hmac-sha the process
is something like this (in kernel) error checking removed ;-):

init:
	struct cryptoini  alg[2];

	alg[0].cri_alg  = CRYPTO_AES_CBC;
	alg[0].cri_klen = aes key length in bits;
	alg[0].cri_key  = ptr to aes key data;
	alg[0].cri_next = &alg[1];

	alg[1].cri_alg  = CRYPTO_SHA1_HMAC;
	alg[1].cri_klen = sha1 key length in bits;
	alg[1].cri_key  = ptr to sha1 key data;
	alg[1].cri_mlen = result len (ie., 12 for ipsec, 20 for normal sha)

	err= crypto_newsession(&cryptoid, &alg[0], CRYPTOCAP_F_HARDWARE)

encrypt some data:

	struct cryptop *crp;
	struct cryptodesc *crd[2];

	crp = crypto_getreq(2);
	crd[0] = crp->crp_desc;
	crd[1] = crd[0]->crd_next;

	crd[0]->crd_alg    = CRYPTO_SHA1_HMAC;
	crd[0]->crd_key    = sha key pointer;
	crd[0]->crd_klen   = sha key len in bits;
	crd[0]->crd_inject = offset in buffer for sha result
	crd[0]->crd_mlen   = size of result
	crd[0]->crd_skip   = start hashing this far into buffer;
	crd[0]->crd_len    = length of input buffer for SHA

	crd[1]->crd_alg    = CRYPTO_AES_CBC;
	crd[1]->crd_key    = aes key pointer;
	crd[1]->crd_klen   = aes key len in bits;
	crd[1]->crd_inject = offset in buffer to write the IV when done
	crd[1]->crd_skip   = start cipher this far into buffer;
	crd[1]->crd_len    = length of input buffer for AES

	crp->crp_ilen      = total length of input buffer
	crp->crp_flags     = CRYPTO_F_* flags (ie SKB/IOV etc);
	crp->crp_buf       = pointer to buf/iov/skb
	crp->crp_callback  = function to call when done
	crp->crp_sid       = cryptoid from newsession;
	crp->crp_opaque    = arg to pass back to callback

	crypto_dispatch(crp)

Hope that helps describe how it's current chained together a little.

> How do you suggest we go about this? 

First we need to work out what is missing from the current API that you will
need and then we can decide on how to incorporate it.

Also,  have you looked at the latest crypto API in the linux kernel.
It supports a lot of alg's and combinations.  The doco can be a bit poor but
it may already be capable of what you want.  There is also support for async
HW crypto now.  While I am more than happy to have people improve OCF it
wouldn't be fair to leave out the kernel API as there is a lot of work going
on there and it's part of the kernel,  something OCF will never be ;-)

Cheers,
Davidm

> -----Original Message-----
> From: David McCullough [mailto:Dav...@se...] 
> Sent: Friday, 29 January, 2010 6:18 PM
> To: Gokhale, Gandhar
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] AEAD support in OCF
> 
> 
> Jivin Gokhale, Gandhar lays it down ...
> > Hi David,
> > Thanks for your reply. I may be missing something here. 
> > 
> > As per my understanding what the AEAD mode algorithms typically need in input is: key, nonce, payload and AAD (Additional Authentication Data). Of these, nonce and AAD are very much algorithm dependent (as specified in respective RFCs. E.g. http://tools.ietf.org/html/rfc4106 and http://tools.ietf.org/html/rfc4309). The cryptodesc or cryptoini structures don't appear to have fields that could hold all these values. Are any of the existing fields being overloaded to be used for this? None of the drivers included in the code (ocf-linux-20090901) have any of the AEAD algorithms supported. Further, I don't see the #define values for any AEAD algorithms in the CRYPTO_* list in the cryptodev.h file. I'd would expect something like #define CRYPTO_RIJNDAEL128_GCM 26  
> > #define CRYPTO_RIJNDAEL128_CCM 26 etc.
> > However, I don't find them there.
> > 
> > Am I looking at wrong code?
> 
> I was under the impression that AEAD was a term used to refer to hash/cipher
> combinations.  Perhaps I have that wrong :-(
> 
> Plenty of the drivers do AES/DES+MD5/SHA.  In other words something like:
> 
> 		aead-aes-cbc-hmac-sha
> 
> but you are right,  none of them do CCM/GCM or counter modes. Do you need
> more inputs to the algs than aead-aes-cbc-hmac-sha would require ?
> OCF allows for each cipher/hash in a session to have it's own keys, iv's etc.
> If that is enough then you probably just need to add the ciphers/auth algs
> you want to the headers and implement them in your driver.
> 
> Cheers,
> Davidm
> 
> 
> > -----Original Message-----
> > From: David McCullough [mailto:Dav...@se...] 
> > Sent: Friday, 29 January, 2010 4:59 PM
> > To: Gokhale, Gandhar
> > Cc: ocf...@li...
> > Subject: Re: [Ocf-linux-users] AEAD support in OCF
> > 
> > 
> > Jivin Gokhale, Gandhar lays it down ...
> > > Hi,
> > > 
> > > I??m working on designing an OCF driver to be used by Linux IPsec stack. I??m trying to gather information about how ??aead?? (Authenticated Encryption with Associate Data) type of algorithms can be supported with OCF. I searched this mailing list but could not get any discussion on this particular topic. Have any aead algorithms been supported via OCF? If yes, is there any resource that discusses the details of the same? Any help is highly appreciated.
> > 
> > OCF has always been able to do AEAD.
> > 
> > Not sure if it's documented specifically.  The OCF design paper discusses
> > alg chaining (AEAD wasn't the term back then ;-)
> > 
> > 	http://openbsd.org/papers/ocf.pdf
> > 
> > Almost all the existing drivers implement it and openswan ipsec_ocf.c
> > gives you a fairly easy to follow example of how to use it.
> > 
> > If you need more info feel free to ask at any time,
> > 
> > Cheers,
> > Davidm
> > 
> > -- 
> > David McCullough,  dav...@se...,  Ph:+61 734352815
> > McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org
> > 
> > 
> 
> -- 
> David McCullough,  dav...@se...,  Ph:+61 734352815
> McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org
> 
> 

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org