[prev in list] [next in list] [prev in thread] [next in thread]
List: openssl-dev
Subject: Re: [PATCH] HMAC Processing
From: "Verdon Walker" <VWalker () novell ! com>
Date: 2001-04-30 16:50:15
[Download RAW message or body]
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
vwalker@novell.com
Novell Inc., the leading provider of Net Services Software
www.novell.com
> > > drh@celocom.com 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: shenson@drh-consultancy.demon.co.uk
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: drh@celocom.com PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4611.1300" name=GENERATOR></HEAD>
<BODY style="MARGIN-TOP: 2px; FONT: 10pt MS Sans Serif; MARGIN-LEFT: 2px">
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>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.<BR></DIV>
<DIV>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.</DIV>
<DIV> </DIV>
<DIV>Verdon Walker<BR>(801) 861-2633<BR><A
href="mailto:vwalker@novell.com">vwalker@novell.com</A><BR>Novell Inc., the
leading provider of Net Services Software<BR><A
href="http://www.novell.com">www.novell.com</A></DIV>
<DIV> </DIV>
<DIV>>>> drh@celocom.com 04/28/01 06:41AM >>><BR>I'd missed
this comment earlier, hence the reason I didn't reply...<BR><BR>> Verdon
Walker wrote:<BR>> <BR>> <BR>> Basically, in tls1_P_hash() (in
ssl/t1_enc.c), the assumption is made<BR>> that an HMAC_CTX can be used
multiple times by simply memcpy'ing it<BR>> into a temporary structure. This
works if the context is a complete<BR>> representation of the entire state of
the HMAC. It may not work if the<BR>> ctx has pointers or references to
additional information that is not<BR>> copied by this process (as is the
case with the crypto lib we are<BR>> using). This problem is fairly simple to
fix in this case because the<BR>> temporary context can simply be computed
along side the other rather<BR>> than memcpy to it. (This may be slightly
less efficient, but is<BR>> certainly a cleaner implementation.)<BR>>
<BR><BR>Well there are some assumptions of this sort already in places
for<BR>EVP_MD_CTX and EVP_CIPHER_CTX. They occasionally call
EVP_MD_CTX_copy()<BR>which just mempcpy's the buffer.<BR><BR>Again this is OK
for internal stuff but some other digest forms wont<BR>work.<BR><BR>What is
really needed is an additional function in EVP_MD which can be<BR>set to provide
an implementation specific copy operation.<BR><BR>As far as HMAC is concerned we
could either EVP_MD_CTX_copy() the<BR>relevant operations or have some kind of
HMAC 'method' where the whole<BR>operation can be placed under application
control.<BR><BR>> This patch also includes a couple of fixes to code that use
HMAC, but<BR>> never call HMAC_cleanup. This is critical, again, if the
HMAC_CTX<BR>> contains any references to other objects that must be cleaned
up.<BR>> <BR><BR>Hmmm... is there a problem with cleaning up in
HMAC_Final()?<BR><BR>Steve.<BR>-- <BR>Dr Stephen N. Henson. <A
href="http://www.drh-consultancy.demon.co.uk/">http://www.drh-consultancy.demon.co.uk/</A><BR>Personal \
Email: shenson@drh-consultancy.demon.co.uk <BR>Senior crypto engineer, Celo
Communications: <A
href="http://www.celocom.com/">http://www.celocom.com/</A><BR>Core developer of
the OpenSSL project: <A
href="http://www.openssl.org/">http://www.openssl.org/</A><BR>Business Email:
drh@celocom.com PGP key: via
homepage.<BR>______________________________________________________________________<BR>OpenSSL \
Project \
\
<A href="http://www.openssl.org/">http://www.openssl.org</A><BR>Development
Mailing
List \
openssl-dev@openssl.org<BR>Automated List
Manager \
majordomo@openssl.org<BR></DIV></BODY></HTML>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic