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
