Yes, we should be able to use the API with raw data. My point was to treat the input as raw when it's truly raw, not all the time, otherwise we may not get optimal performance.
Alex On 10 October 2014 16:45, Ola Liljedahl <[email protected]> wrote: > Would we still be able to use the crypto API for encryption/decryption and > secure hashing of raw (non-packet) data? > Petrí once mentioned some use cases here, e.g. encryption of logs or other > sensitive data before they are uploaded. I don't know if the ODP crypto API > is the best for such purposes through, there are other API's that might be > better for non-ODP programs. > > -- Ola > > > On 10 October 2014 09:37, Alexandru Badicioiu < > [email protected]> wrote: > >> Mike, >> this is the thing that I wanted to discuss - if we have a requirement for >> such a behavior to test or not. This is one idea I got about the crypto API >> implementation - it should be protocol agnostic and I wanted to find a test >> case that would fail for an existing protocol aware implementation. >> However, my belief is that the implementations should be protocol aware >> (I'm not talking about protocol offloading) because of two reasons : >> - crypto API arguments are packets, not plain buffers. As such, they are >> expected to have a well known structure and protocol specific metadata. >> - performance : applications may do better if they let the platform do >> some protocol-aware operation before the crypto op. For example, in case of >> AH protocol there's no need for the application to zero the ICV in each >> packet, nor copying the ICV somewhere else if the platform supports S/G >> lists as input for crypto . The zero-ICV part can be supplied by the >> implementation as an element in an S/G list. >> Another example - the IV and the cipher range are contiguous for ESP >> packets and the implementation can benefit by not making an S/G list but a >> single contiguous buffer as input for the crypto engine. >> So I think that a crypto implementation should satisfy the requirement >> for symmetry but not by treating the input as plain in all cases. >> >> Alex >> >> On 9 October 2014 20:40, Mike Holmes <[email protected]> wrote: >> >>> Alex can you add a bug ? >>> https://bugs.linaro.org/enter_bug.cgi?product=OpenDataPlane >>> >>> Also will you be adding this case to the crypto unit test ? >>> If we have it as a test describing the behavior we do want it will be >>> clear when the bug is solved. >>> >>> Mike >>> >>> >>> On 9 October 2014 09:18, Robbie King (robking) <[email protected]> >>> wrote: >>> >>>> 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); >>>> >>>> ------- >>>> >>>> } >>>> >>>> >>>> >>>> _______________________________________________ >>>> lng-odp mailing list >>>> [email protected] >>>> http://lists.linaro.org/mailman/listinfo/lng-odp >>>> >>>> >>> >>> >>> -- >>> *Mike Holmes* >>> Linaro Sr Technical Manager >>> LNG - ODP >>> >> >> >> _______________________________________________ >> lng-odp mailing list >> [email protected] >> http://lists.linaro.org/mailman/listinfo/lng-odp >> >> >
_______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
