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
