[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <002501cd9685$a9c7c1f0$fd5745d0$@net>
Date: Wed, 19 Sep 2012 11:41:48 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: 1.7.9-jumbo-7
This brings up a 'good' issue to discuss. In many places we are using oSSL
default #define constants. We probably should NOT do this, since we may not
be running under oSSL. We have taken it to the point, where we 'emulate'
and define the same constants on some non oSSL builds, to use the same name
as the oSSL.
What I believe we 'should' do is to have our OWN set of constants. Then if
under oSSL build, we set out constants to use the oSSL. If building under
OSX, we use theirs. If under wysiwyg-crypt, we theirs, etc. If our own, we
simply set them appropriately.
So, we could have
#ifdef oSSL
#define JOHN_SHA_BUF_SIZ SHA_BUF_SIZ
#else if OSX_crypt
#define JOHN_SHA_BUF_SIZ APPLE_SHA_BUF_SIZ // or whatever it should be
#else if Xanadu_crypt
#define JOHN_SHA_BUF_SIZ SHA_BUFFER_LEN
#define JOHN_SHA_BUF_SIZE what_ever_is_appropriate
#endif
In this way, we hide the constants from each type we 'support', and really,
hopefully only have to modify a single header, when adding support for new
crypt libs.
Yes, hard to do in multiple authored jumbo formats, where we still have
people coding things like: #include <openssl/sha.h> which ties that format
directly to oSSL. But starting to take internal ownership of some of this,
and then slowly working the formats to use that, will make adding new crypt
libs easy (er) which will make john more easily portable to other systems,
without having to internally code each crypt type (like we have done for
many).
But I think the apple 'common' crypt has caused some of these growing pains
to show, since it is really not compatible with oSSL, at the lower level.
It is compatible 'above' the CTX level, but there are some things that are
not quite the same.
Jim.
>From: magnum [mailto:john.magnum@...hmail.com]
>
>The problem was that OSX native llvm use a SHA_BUF_SIZ of 80 because
>it's faster (this is added since Jumbo-6). Certain SSE2 optimizations in
>hmac-sha1 did not bring that into the equation.
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.
