Hi, I am using 1.0.1h, but believe the problem still exists in later versions.
I have following code to calculate HMAC for messages in a multi-threaded application. The locking is expensive so locking on hmac calculation of every message is unaffordable. sessesion initialization - initialize the context with evp_digest only, engine lookup will occur which needs to lock: HMAC_CTX_init(&ctx); HMAC_Init_ex(&ctx, NULL, 0, evp_digest, NULL); hmac calculation - update context with key only, no engine lookup should occur. However, engine lookup does occur inside HMAC_Init_ex. This means lock is called for every message, that is too often. HMAC_Init_ex(&ctx, key_in, key_len, NULL, NULL); HMAC_Update(&ctx, msg_buffer, msg_len); HMAC_Final(&ctx, hmac_buffer, &hmac_len) Had a look into OpenSSL's source code, the reason for the problem is that there is no engine available for the evp_digest (sha256 in my case). The code that I think should be corrected are: 1. in HMAC_Init_ex(HMAC_CTX *ctx, const void *key, int len, const EVP_MD *md, ENGINE *impl): even if I pass NULL for md, it will pass the non-NULL one that I passed in previous call to EVP_DigestInit_ex() anyway 2. in EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl): even if I pass NULL for type, engine lookup is still not bypassed. And that is because the last engine lookup returned NULL and the bypass check requires that we got a valid engine before. And when it checks if type is a new digest compared with the existing one in the context (digest.c:202), it does not consider the case when type==NULL. This may seem a minor issue, but for multi-threaded high performance applications, the impact incurred by the unnecessary locking is huge. There is no way to work it around unless make update to OpenSSL. Let me know if you need more information. Thanks Leopert Li _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
