Hi Robbie, I noticed myself that the application takes care of zeroing mutable fields in the IP header but it does not do the same thing with the AH ICV, leaving this task to the implementation. While ODP crypto API wanted to be protocol agnostic, the current (linux-generic) implementation is not. This made me wondering how much of protocol aware an implementation can be or could we make use of protocol awareness for performance improvement, for example. Max's proposal indeed removes this protocol awareness from the implementation, but is not optimal from the performance point of view; placing the ICV somewhere else is not either. For crypto engines which can handle in/out S/G lists (my case) an input S/G list for ICV computation can be used instead of the contiguous auth range having as zeroized ICV a fixed buffer provided by the implementation. Another question related to the application - I noticed it attempts to use combined sessions for decoding single protocol input packets (AH or ESP) - is the HW always capable of dealing with this?
Thanks, Alex On 20 August 2014 17:05, Robbie King (robking) <[email protected]> wrote: > Hi Alex, again my apologies to all for dropping the ball on this. > > > > I had clarified with Max how CDAL expects the ICV to be handled. That is > not to > > say that ODP crypto has to behave this way, but it can hopefully > facilitate emulating > > the desired CDAL behavior. Here is Max’s clarification with some > rewording to > > reflect ODP crypto API terminology. > > > > 1) In encryption direction, “hash_result_offset” is the location where the > computed > > ICV will be placed. The buffer range from “auth_range” is used for the > computation of > > the ICV. Any preparation for the buffer (e.g. in the case AH, the ICV > location in the header > > needs to be zeroed out) is the responsibility of the caller. > > 2) In decryption direction, “hash_result_offset” is the location where the > packet ICV is > > located and the computed ICV needs to be compared with it. The buffer > range from “auth_range” > > is used for the computation of the ICV. Any preparation for the buffer > (e.g. in the case AH, the > > ICV location in the header needs to be zeroed out) is the responsibility > of the caller. Also, please > > note that, for AH case, the caller needs to relocate the packet ICV from > AH header to a location > > not inside the “auth_range”. > > > > So Max’s proposal puts the burden of zero’ing the ICV in the > authentication (#2) direction > > on the application, not the implementation (implementation does it today). > > > > For me the big question is, how do we handle “hash_result_offset” if it is > by design not > > inside the packet for authentication? Does the application grow the > packet by 12 bytes > > and place the original ICV value at the end of the packet, then trim it > back off post > > MD5 generation? > > > > Thanks, > > Robbie > > > > > >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
