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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ