[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 12 Apr 2013 16:26:44 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: jumbo pull request #255 (trouble with static builds)
From: Solar Designer [mailto:solar@...nwall.com]
>> this is one of two possible fixes, the alternative is that a proper
>> check for an installed openssl is done (or the user can choose) and if
>> so add both -DHAVE_OPENSSL to CFLAGS and -lssl -lcrypto to LDFLAGS.
>
>A better fix may be to rename our interfaces and thus avoid the clash with
OpenSSL's. As an option, we could add >some #define's renaming the
interfaces (e.g. adding leading "john_") to the start of md[45].h. We
already use >this approach for "int64".
This was the approach I did with the sha2.c code, the 'generic' work around
code, for older versions of oSSL, which did not implement sha2 functions.
The 'official' oSSL name is SHA512_CTX. Mine is sha512_ctx, and there is a
#define making SHA512_CTX when used in code work just fine. I have a
function called sha512_init(x), and there is a #define that allows a normal
looking call to SHA512_Init(x) (the proper oSSL interface), to simply call
my function.
Yup, it probably would have been better to simply use something like
jtr_SHA512_Init(x) as my sha2 function interface, and then properly define
SHA512_Init(x) to use that function. In hind sight, I should have coded them
that way, but did not.
However, the code using unique external names is MUCH easier to use,
avoiding linkage issues like this completely. That was one of the uglier
things, which I did not fully grasp, when I started working on JtR. You can
still see the confusion within the dynamic stuff.
It really should not take all that much, to change the internal md4/5 and
sha1 scalar to have their own unique external names, and then make the
header files do the #define magic to hide these modifications from end
users. Then if the end user simply does #include "md5.h" vs #include
<openssl/md5.h>, then the build environment could be smart enough to know
when to use ossl, and when not to.
One thing you get in some builds of JtR, is the MD5_X2, SHA1_X2, etc, which
can make things MUCH faster than oSSL on some platforms. So it is not
simply the initial 'clearing' and post final clearing that is saved with
internal JtR hash code. Note, the 2x DOES break the oSSL interfaces anyway.
Jim.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
