[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 19 Sep 2012 19:03:51 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
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!
magnum
On 19 Sep, 2012, at 18:41 , jfoug <jfoug@....net> 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
> #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.
