16 Dec
2024
16 Dec
'24
4:05 p.m.
Hi Raymond,
Le 16/12/2024 à 16:01, Raymond Mao a écrit :
Hi Philippe,
On Mon, 16 Dec 2024 at 07:48, Philippe REYNES philippe.reynes@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.reynes@softathome.com> wrote: Adds the support of the hmac based on sha256. This implementation is based on rfc2104. Signed-off-by: Philippe Reynes <philippe.reynes@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?
Correct
If this is the case, I would prefer to use mbedtls_md_hmac() since it brings more simplicity.
Ok, I do the change.
Thanks for this fast answer.
Regards, Raymond
Regards,
Philippe