Hi Philippe,
On Mon, 16 Dec 2024 at 07:48, Philippe REYNES <
philippe.rey...@softathome.com> wrote:
> Hi Raymond,
>
>
> Le 13/12/2024 à 17:49, Raymond Mao a écrit :
>
>
>
> *This Mail comes from Outside of SoftAtHome: *Do not answer, click links
> or open attachments unless you recognize the sender and know the content is
> safe.
> Hi Philippe,
>
> On Thu, 12 Dec 2024 at 08:37, Philippe Reynes <
> philippe.rey...@softathome.com> wrote:
>
>> Adds the support of the hmac based on sha256.
>> This implementation is based on rfc2104.
>>
>> Signed-off-by: Philippe Reynes <philippe.rey...@softathome.com>
>> ---
>> include/u-boot/sha256.h | 4 ++++
>> lib/sha256_common.c | 48 +++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 52 insertions(+)
>>
>> diff --git a/include/u-boot/sha256.h b/include/u-boot/sha256.h
>> index 44a9b528b48..2f12275b703 100644
>> --- a/include/u-boot/sha256.h
>> +++ b/include/u-boot/sha256.h
>> @@ -45,4 +45,8 @@ void sha256_finish(sha256_context * ctx, uint8_t
>> digest[SHA256_SUM_LEN]);
>> void sha256_csum_wd(const unsigned char *input, unsigned int ilen,
>> unsigned char *output, unsigned int chunk_sz);
>>
>> +void sha256_hmac(const unsigned char *key, int keylen,
>> + const unsigned char *input, unsigned int ilen,
>> + unsigned char *output);
>> +
>> #endif /* _SHA256_H */
>> diff --git a/lib/sha256_common.c b/lib/sha256_common.c
>> index 7041abd26d9..46262ea99a2 100644
>> --- a/lib/sha256_common.c
>> +++ b/lib/sha256_common.c
>> @@ -48,3 +48,51 @@ void sha256_csum_wd(const unsigned char *input,
>> unsigned int ilen,
>>
>> sha256_finish(&ctx, output);
>> }
>> +
>> +void sha256_hmac(const unsigned char *key, int keylen,
>> + const unsigned char *input, unsigned int ilen,
>> + unsigned char *output)
>> +{
>> + int i;
>> + sha256_context ctx;
>> + unsigned char keybuf[64];
>> + unsigned char k_ipad[64];
>> + unsigned char k_opad[64];
>> + unsigned char tmpbuf[32];
>> + int keybuf_len;
>> +
>> + if (keylen > 64) {
>> + sha256_starts(&ctx);
>> + sha256_update(&ctx, key, keylen);
>> + sha256_finish(&ctx, keybuf);
>> +
>> + keybuf_len = 32;
>> + } else {
>> + memcpy(keybuf, key, keylen);
>> + keybuf_len = keylen;
>> + }
>> +
>> + memset(k_ipad, 0x36, 64);
>> + memset(k_opad, 0x5C, 64);
>> +
>> + for (i = 0; i < keybuf_len; i++) {
>> + k_ipad[i] ^= keybuf[i];
>> + k_opad[i] ^= keybuf[i];
>> + }
>> +
>> + sha256_starts(&ctx);
>> + sha256_update(&ctx, k_ipad, sizeof(k_ipad));
>> + sha256_update(&ctx, input, ilen);
>> + sha256_finish(&ctx, tmpbuf);
>> +
>> + sha256_starts(&ctx);
>> + sha256_update(&ctx, k_opad, sizeof(k_opad));
>> + sha256_update(&ctx, tmpbuf, sizeof(tmpbuf));
>> + sha256_finish(&ctx, output);
>> +
>> + memset(k_ipad, 0, sizeof(k_ipad));
>> + memset(k_opad, 0, sizeof(k_opad));
>> + memset(tmpbuf, 0, sizeof(tmpbuf));
>> + memset(keybuf, 0, sizeof(keybuf));
>> + memset(&ctx, 0, sizeof(sha256_context));
>> +}
>> --
>> 2.25.1
>>
>> The sha256 hmac common implementation now sounds good.
> Do you have a comparison of performance with the MbedTLS high-level API
> mbedtls_md_hmac()?
> I am wondering if it is worth using this API specially when MbedTLS is
> enabled,
> since it significantly simplifies the implementation.
>
> I have done some test, and the legacy implementation is the fastest.
> To do my test, I have run 1 000 000 times the unit test for hmac.
> here the result:
> common + legacy => 7 seconds
> common + mbedtls => 17 seconds
> mbedtls => 17 seconds
>
> I have kept common + mbedtls for the v5.
> But I may use a pure mbedtls if you prefer.
>
>
> If my understanding is correct, "common + mbedtls => 17 seconds" means
mbedtls enabled and with your patch,
while "mbedtls => 17 seconds" means using mbedtls_md_hmac(), right?
If this is the case, I would prefer to use mbedtls_md_hmac() since it
brings more simplicity.
Regards,
Raymond
