As Tri Phan once put it:
> I'm using openSSL-0.9.1c's EVP_BytesToKey to generate a DES
> encryption key for EVP_des_cbc() and EVP_des_ede3_ofb(). I can run
> my application sucessfully as an NT application, NSAPI DLL within
> NES 3.6.1 (on NT), Sun Solaris application, or Sun Solaris shared
> object without NSAPI. The same encyption is derived for my given
> password, salt, and iteration count.
>
> However, when I run my application as an NSAPI share object within
> Netscape Enterprise Server (NES) 3.61 on Solaris, a different DES
> encryption key is derived for the same password, salt, and iteration
> count.
Keep in mind when working with dynamically loaded object files that
the symbols already found in the program will override any symbols
present in your loaded code (or anything linked to it). NS Enterprise
Server has several symbols that conflict with the symbols in
ssleay/openssl. When such a conflict exists, the Netscape version of
the routine (which likely has different calling conventions or
semantics) is used in preference to the OpenSSL version.
I ran into this problem when trying to use SSL calls from within an
NSAPI. I solved it by hacking the OpenSSL source to tweak the names
of the colliding routines, changing *_Update to *_update:
find /src/openssl-0.9.1c -type f \( -name '*.[ch]' -o -name '*.org' \) -exec egrep -s
'(MD2|MD5|SHA1)_Update' {} \; -print | xargs perl5 -i -pe
's/(MD2|MD5|SHA1)_Update/$1_update/g;'
As the example3.c file appears to use MD5 for the BytesToKey routine,
this is the likely culprit.
%% Christopher A. Bongaarts %% [EMAIL PROTECTED]
%% ADCS - Internet Enterprise %% http://umn.edu/~cab
%% University of Minnesota %% +1 (612) 625-1809
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
