Hi Alex, Sorry just getting back to you. I was thinking about the ICV thing some more this AM. Currently we’re using the “hash_result_offset” as both an input and output variable. What if we have “hash_result_offset” be the offset at which the implementation stores the computed ICV value, and have a new variable “hash_verify_ptr” that is a memory pointer to the value to be compared against when doing the verify operation?
This way the implementation has more freedom as to how to accomplish the verification of the ICV. On your second question, I’m not sure I understand what you mean by “combined session”? From: Alexandru Badicioiu [mailto:[email protected]] Sent: Wednesday, August 20, 2014 10:51 AM To: Robbie King (robking) Cc: Taras Kondratiuk; lng-odp-forward ([email protected]); Bala Manoharan Subject: Re: Clarification of ICV handling in linux-generic crypto... 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]<mailto:[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
