Re: [Ocf-linux-users] AEAD support in OCF
Brought to you by:
david-m
From: Gokhale, G. <Gan...@ls...> - 2010-01-29 14:23:53
|
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. How do you suggest we go about this? Thanks and regards, Gandhar Gokhale -----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 |