This is a discussion on Re: HMAC_Final()/tls1_P_hash() problem with PKCS#11 - Openssl ; On Sun, 24 Jun 2007, Nanno Langstraat wrote: >> OpenSSL: ctx init, dgst init/update/final, ctx cleanup >> PKCS#11: dgst init/update/final >> >> where some memory is allocated in dgst init and freed in ctx cleanup >> (not dgst final) in ...
On Sun, 24 Jun 2007, Nanno Langstraat wrote:
>> OpenSSL: ctx init, dgst init/update/final, ctx cleanup
>> PKCS#11: dgst init/update/final
>> where some memory is allocated in dgst init and freed in ctx cleanup
>> (not dgst final) in OpenSSL, but allocated in dgst init and freed in dgst
>> final in PKCS#11 tokens. So, if you don't call xyzFinal() it's fine wrt
>> memory usage in OpenSSL but it's a problem in PKCS#11 app.
>> it's usually not a problem because when there is digest init there is
>> also digest final some time after that. However, not for HMAC computation.
> This sounds almost exactly why I added the SHA1_Drop() function to the
> "save/load SHA1 state" patch, discussed on this list a week ago.
> (or SHA1_Abandon(), SHA1_Cancel(), whatever name you prefer for the function)
> Even though it's a no-op for the current SHA1 C implementation, it creates a
> clean hook to deallocate any memory without having to do an unnecessary Final()
hi Nanno, I don't think it's very similar. The problem is that one
can't change PKCS#11 API. EVP_MD_CTX_cleanup() has its counterpart in the
engine but not in the PKCS#11 token.
the only way how to deallocate memory in the token allocated in
C_DigestInit() is to call C_DigestFinal(), which means unless app calls
EVP_DigestFinal() there is a leak.
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org