Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Sep 2012 19:03:51 +0200
From: magnum <>
Subject: Re: 1.7.9-jumbo-7

What you write is true in general, but the bug in question was not about that: The SHA_BUF_SIZ I'm talking about only exist in JtR's own sse-intrinsics.c code. It's set to 80 for Simon's original 80x4 buffer SSE2 SHA-1, and 16 for your later 16x4 code that use buffers similar to MD4 and MD5 (except for endianness). Your code is faster on every platform I have tried except OSX w/ llvm. So I modifed x86-64.h to use 80 for these builds - and that triggered the bug!


On 19 Sep, 2012, at 18:41 , jfoug <> wrote:

> 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
> #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_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 []
>> 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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ