Agreed. I thought we had created a bug for this but apparently not. The last
discussion that I remember having is in the attached email.
From: [email protected]
[mailto:[email protected]] On Behalf Of Alexandru Badicioiu
Sent: Wednesday, October 08, 2014 7:35 AM
To: [email protected]
Subject: [lng-odp] crypto session/operation symmetry testing
Hi, I'd like to get some input on the validity of the following crypto testing
scenario - two symmetric sessions, with the same parameters except the
operation (ENCODE/DECODE) and testing that the output of the encode session can
be decoded by the other one and the result is the same as the input to encode
session.
As I see, linux-generic will fail this test in case of authentication when
hash_result_offset is inside the authenticated range (as it is for AH
protocol). The implementation is not symmetric , for encode the ICV is computed
on the authenticated range as it is passed by the application but for ICV
checking the implementation clears the ICV prior checking:
static
enum crypto_alg_err md5_check(odp_crypto_op_params_t *params,
odp_crypto_generic_session_t *session)
{
-----------------
/* Adjust pointer for beginning of area to auth */
data += params->auth_range.offset;
icv += params->hash_result_offset;
/* Copy current value out and clear it before authentication */
memset(hash_in, 0, sizeof(hash_in));
memcpy(hash_in, icv, bytes);
memset(icv, 0, bytes);
memset(hash_out, 0, sizeof(hash_out));
/* Hash it */
HMAC(EVP_md5(),
session->auth.data.md5.key,
16,
data,
len,
hash_out,
NULL);
--------------
}
static
enum crypto_alg_err md5_gen(odp_crypto_op_params_t *params,
odp_crypto_generic_session_t *session)
{
-------------------
/* Adjust pointer for beginning of area to auth */
data += params->auth_range.offset;
icv += params->hash_result_offset;
/* Hash it */
HMAC(EVP_md5(),
session->auth.data.md5.key,
16,
data,
len,
hash,
NULL);
-------
}
--- Begin Message ---
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
--- End Message ---
_______________________________________________
lng-odp mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/lng-odp
