Hi Alex, I wonder could you provide the same information as it would go to odp_crypto.h API description? My, maybe naive, assumption was that if someone reads odp_crypto.h API he/she can go and write ODP code that uses such API. Currently odp_crypto.h does not have any description that passed odp_packet_t should be PDU and what would be different if it has such structure vs another structure. It is just odp_packet_t and couple ranges ...
If your point is that in certain cases with certain recognized PDUs and certain set of input ranges implementation will do much better job that with another PDUs and another input ranges it is fine with me. We already have such difference on trivial level: bigger range means slower processing :). As long as ODP implementation writer does not care about implementation internals and he/she could use API in any possible way permitted by API description in odp_crypto.h it works for me. In such situation as far as testing concerned, it may include variety of payloads starting with generic date placed in odp_packet_t, and specific combinations of PDUs and ranges. Again all combinations permitted by odp_crypto.h should work. If your point that we need to revise odp_crypto.h with more clarifications, then it is indeed more urgent and require immediate attention. Thanks, Victor On 10 October 2014 11:26, Alexandru Badicioiu <[email protected]> wrote: > Raw data means that the implementation cannot assume anything about it, A > packet means a PDU - (Protocol Data Unit in OSI parlance) , the > implementation can (and should) use the fact that it is AH/ESP and so on. > This was my point, if the input is a packet type it should be treated as > such. ODP has packet flags APIs which tell what kind of packet it is. I say > that if implementation uses this protocol knowledge it may offer a better > performance to the application - check my explanation about the ICV in AH > case. But the application should be aware of this - why to move the ICV > outside the auth_range and clear the ICV field if implementation can do > better ? > Another point - current linux-generic implementation md5_check() function > always saves the ICV and clears the ICV field as it is required for AH > protocol. If the imput represents an ESP ICV which is outside the > auth_range, it's just doesn't make sense. > Placing part of protocol knowledge in the application and part in the > implementation as it is now in linux-generic is not consistent nor optimal. > Placing all protocol knowledge in the application is consistent but may not > be optimal. Placing all protocol knowledge in the implementation is > consistent and can achieve optimality. > > Alex > > > > > On 10 October 2014 17:29, Victor Kamensky <[email protected]> > wrote: >> >> 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
