To clean up, just call MD5_Final and ignore the result.
When I said it depended on which OpenSSL API you were
using, it was less about the version of OpenSSL and more
about the specific function names, as there is more than
one set of functions that can do the MD5. I see from
your latest mail below that you are using the functions
named "MD5 underscore Init/Update/Final" as found in
md5.h . Those give you full control over the MD5_CTX
structure, you even have to allocate and free it yourself.
On 1/28/2012 8:12 AM, Prabu RM wrote:
Hi Jakob,
Thanks for your info. The openssl version currently we used to is
0.9.8r. Also we need a clarification for one more thing.
Is there a way to cleanup the missed CTX from memory? Consider the
below scenario.
*File 1*
--> MD5_Init
--> MD5_Update
--> MD5_Update
--> MD5_Update
--> Missed MD5_Final
*File 2*
--> MD5_Init
--> MD5_Update
--> MD5_Update
--> MD5_Update
--> MD5_Final
Here we feel there could be a memory leak on openssl libraries when
MD5_Final() is missed. It would be better if an MD5_ReInit() or
MD5_ReSet() like functions which should clean up the previous missed
CTX before calling MD5_Init() for next file. Since we used to call
Md5_Init(),MD5_Update and MD5_Final from different places w.r.t
application design if we missed Md5_Final some leak will happen at
openssl library level. Right?
Regards,
Prabu RM.
On Fri, Jan 27, 2012 at 9:29 PM, Jakob Bohm <jb-open...@wisemo.com
<mailto:jb-open...@wisemo.com>> wrote:
Depends which of the OpenSSL APIs you use to do the hashing. Some
give you a usable context pointer where you can access the bytes
that need saving by following pointers into "internal" structures,
others do not.
However note that there is another problem in such cases: When a
connection is interrupted, it is very common that the server and
client do not completely agree on the exact byte offset of the
interruption (because some bytes sent by the server never reached
the client but were lost in hardware and software buffers). So
the saved CTX will usually be for different byte offsets at each
end and one end will have restart its MD5 calls at a different
byte offsets than where it restarts its transmission calls.
On 1/27/2012 8:22 AM, Prabu RM wrote:
Hi Jakob,
Thanks for your reply and we will try as you say. Is there any
other way to store the CTX at block level in RDBMS like MySQL?
Say if the transfer is interrupted at 500 MB and i know at
which block the transfer has been interrupted. In same
scenario if i know the CTX of already sent block then it will
avoid the process of MD5 update of already stored 500 MB
before the next transfer schedule. Simply is it possible to
get the CTX at block level and proceed?
Regards,
Prabu RM.
On Thu, Jan 26, 2012 at 7:21 PM, Jakob Bohm
<jb-open...@wisemo.com <mailto:jb-open...@wisemo.com>
<mailto:jb-open...@wisemo.com <mailto:jb-open...@wisemo.com>>>
wrote:
On 1/26/2012 7:25 AM, Prabu RM wrote:
Hi,
We have been used to CRC via MD5 hash algorithm for a
file to
be transferred in socket we kepp below steps.
_*At Client side:*_
1.Md5 Init()
2.MD5 Update
MD5 Update
MD5 Update
MD5 Update
.
.
.
3.MD5 Final
4.Get Checksum *C1*
_*At Server side:*_
1.Md5 Init()
2.MD5 Update
MD5 Update
MD5 Update
MD5 Update
.
.
.
3.MD5 Final
4.Get Checksum *C2*
*if(C1 == C2)
{
crc is sucess!
}
*
What my case is if i transfer a file with large size
about 1GB
and if the socket closed at the time of file reaching 500MB
and i re-transfer the file in next schedule. In this
how can i
work with MD5,SHA hash algorithms where i wish "Where
it left
off"?
Could you please help me? Simply how can i handle CRC of
incomplete file in next schedule? Is there any other way
rather than transferring entire file?
Regards,
Prabu RM.
Simple:
At Server side first pass the bytes from the previously
received 500MB to MD5 Update, then the bytes of the
sent 500MB, so MD5 Update gets the same bytes as for a
full transfer but with only the missing bytes
transferred.
At Client side first pass the 500MB that will not be
sent to MD5 Update, then the 500MB that are sent.
If you use HTTP with the "Range" and "MD5-something"
headers for this job, be sure your client handles the
possibility of the server choosing to send a larger
fraction of the file than requested (it is allowed to
do that, by specifying a different range or the entire
file in its response HTTP headers). For the excess
bytes you can decide to use either the newly received
of the previously received values of those bytes, just
make sure you give MD5 Update the bytes that you will
actually put/keep in the final file.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
<mailto:openssl-users@openssl.org>
<mailto:openssl-users@openssl.org
<mailto:openssl-users@openssl.org>>
Automated List Manager majord...@openssl.org
<mailto:majord...@openssl.org>
<mailto:majord...@openssl.org <mailto:majord...@openssl.org>>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
<mailto:openssl-users@openssl.org>
Automated List Manager majord...@openssl.org
<mailto:majord...@openssl.org>
