Re: [PATCH] HMAC Processing

[Verdon Walker]

While I agree that adding some sort of EVP_MD_CTX_copy() for HMAC's would be much better than a memcpy(), it would not solve our problem. Our crypto library does not support any type of copy operation for contexts so we would still have a problem.   And yes, we have seen, that Digest contexts are copied which also causes us some problems. For example, we have had to add code to keep multiple copies of the handshake digest context since we have no way to copy it. On the separate issue of cleaning up HMAC's in HMAC_Final(), there does appear to be a problem doing this (at least in the code in t1_enc.c). There seem to be two different flavors of HMAC_Init(). You can call HMAC_Init() with a key for a full initialization or you can call it with a NULL key and it will reuse the key from the previous Init. I believe this is why a separate cleanup routine was created so that you can specify the difference between being really done and just ready for a value but still planning to do some more processing.   Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell Inc., the leading provider of Net Services Software www.novell.com   >>> [EMAIL PROTECTED] 04/28/01 06:41AM >>> I'd missed this comment earlier, hence the reason I didn't reply... > Verdon Walker wrote: > > > Basically, in tls1_P_hash() (in ssl/t1_enc.c), the assumption is made > that an HMAC_CTX can be used multiple times by simply memcpy'ing it > into a temporary structure. This works if the context is a complete > representation of the entire state of the HMAC. It may not work if the > ctx has pointers or references to additional information that is not > copied by this process (as is the case with the crypto lib we are > using). This problem is fairly simple to fix in this case because the > temporary context can simply be computed along side the other rather > than memcpy to it. (This may be slightly less efficient, but is > certainly a cleaner implementation.) > Well there are some assumptions of this sort already in places for EVP_MD_CTX and EVP_CIPHER_CTX. They occasionally call EVP_MD_CTX_copy() which just mempcpy's the buffer. Again this is OK for internal stuff but some other digest forms wont work. What is really needed is an additional function in EVP_MD which can be set to provide an implementation specific copy operation. As far as HMAC is concerned we could either EVP_MD_CTX_copy() the relevant operations or have some kind of HMAC 'method' where the whole operation can be placed under application control. > This patch also includes a couple of fixes to code that use HMAC, but > never call HMAC_cleanup. This is critical, again, if the HMAC_CTX > contains any references to other objects that must be cleaned up. > Hmmm... is there a problem with cleaning up in HMAC_Final()? Steve. -- Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/ Personal Email: [EMAIL PROTECTED] Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the   OpenSSL project: http://www.openssl.org/ Business Email: [EMAIL PROTECTED] PGP key: via homepage. ______________________________________________________________________ OpenSSL Project                                 http://www.openssl.org Development Mailing List                       [EMAIL PROTECTED] Automated List Manager                           [EMAIL PROTECTED]