On 10 October 2014 06:50, Alexandru Badicioiu <[email protected]> wrote: > 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.
I don't understand this point. What constitute "raw data" vs "packet"? Current odp crypto operation receive odp_packet_t as input. What else do you need? Are you telling that on some (i.e your) platform some combination of values in cipher_range and auth_range would be processed better that other? Thanks, Victor > 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 > _______________________________________________ lng-odp mailing list [email protected] http://lists.linaro.org/mailman/listinfo/lng-odp
