apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: [PATCH] Optimized MD5 implementation from OpenSSL
Date Wed, 03 Jan 2007 00:56:17 GMT


On 01/02/2007 11:01 PM, Justin Erenkrantz wrote:

> 
> However, the big annoying thing is that we declared apr_md5_ctx_t in
> apr_md5.h so it's not an opaque value.  Luckily for us though, OpenSSL's
> MD5 context is smaller than APR's - so an ugly hack works.
> 
> OpenSSL's ctx:
> 
> #define MD5_CBLOCK��64
> #define MD5_LBLOCK��(MD5_CBLOCK/4)
> #define MD5_DIGEST_LENGTH 16
> 
> typedef struct MD5state_st
> {
>    MD5_LONG A,B,C,D;
>    MD5_LONG Nl,Nh;
>    MD5_LONG data[MD5_LBLOCK];
>    unsigned int num;
> } MD5_CTX;

Can we be sure that M5_LONG is always 32bit on all platforms that are
supported by apr-util?

> 
> Our context:
> 
> struct apr_md5_ctx_t {
>     /** state (ABCD) */
>     apr_uint32_t state[4];
>     /** number of bits, modulo 2^64 (lsb first) */
>     apr_uint32_t count[2];
>     /** input buffer */
>     unsigned char buffer[64];
>     /** translation handle�
>      *  ignored if xlate is unsupported
>      */
>     apr_xlate_t *xlate;
> };
> 
> Using the optimized MD5 implementation tends to shave 5%-10% or so off
> Subversion checkout times in rough testing on Solaris 10 AMD64.  
> 
> The performance win tells me that it's probably worth it to investigate
> this further, but if we can't use OpenSSL's MD5 interface, we need to
> duplicate their optimized implementations - which I don't really want to do
> unless we have to do so.

But wouldn't this also solve our possible license problems with RSA regarding
MD5, which is currently investigated?
Plus it would relief us from the ugly hack above.
But regardles of this, would we be able to duplicate their optimized implementation
without getting any copyright trouble with the openssl guys?

Regards

Rüdiger


Mime
View raw message