[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4DDE5A0B.6060409@bredband.net>
Date: Thu, 26 May 2011 15:47:55 +0200
From: magnum <rawsmooth@...dband.net>
To: john-dev@...ts.openwall.com
Subject: Re: SSE bug still there in Jumbo-5-RC6++
Sorry, that was wrong. 33 is not enough. I had them scattered in the
infile but not in the dict.
magnum
On 2011-05-26 15:42, magnum wrote:
> I tried 33*MMX_COEF using a tailored test file with length 32 among
> shorter, seems to work fine.
>
> magnum
>
> On 2011-05-26 15:22, magnum wrote:
>> That's a good cause, but your patch fails selftest for me. Something
>> must be wrong about it. Maybe I should debug it (since you don't see the
>> problem)?
>>
>> Wouldn't 33*MMX_COEF be enough?
>>
>> magnum
>>
>>
>> On 2011-05-26 15:10, JimF wrote:
>>> The patch was due to the password length being 32 bytes, and the 0x80
>>> being stored in the buffer also. It will only show up if cracking a 32
>>> byte password (there are non in the test suite, yet. If we go back to 32
>>> byte memcpy, then we should set max password length to 31 bytes (so the
>>> 0x80 'fits') in the dword contained in the first 32.
>>>
>>> One thing that should be added to the test suite input files is another
>>> 20 candidates (sprinkled through the file), that are the MAX size of the
>>> password allowed for the format (removing 20 other's or simply going to
>>> 1340). Also, we need to add some words to pw.dic that are LONG
>>> passwords, longer than any format can handle, and again spread
>>> throughout the file. Those longer PW'd will hopefully smoke out
>>> overwrite issues. The one where we have the most likelyhood of
>>> overwrites is in md5-gen, since there is no easy way to set a max sized
>>> input password.
>>>
>>> Jim.
>>>
>>> ----- Original Message ----- From: "magnum" <rawsmooth@...dband.net>
>>> To: <john-dev@...ts.openwall.com>
>>> Sent: Thursday, May 26, 2011 5:37 AM
>>> Subject: Re: [john-dev] SSE bug still there in Jumbo-5-RC6++
>>>
>>>
>>>> Erik, Jim,
>>>>
>>>> Please try the attached rawMD5unicode_fmt.c
>>>>
>>>> It solves ALL problems for me on x86-64, x86-sse2 and x86-mmx and the
>>>> OpenLDAPS can be enabled again. Everything passes self tests and test
>>>> suite. It also speed things up as I dropped saved_plain completely and
>>>> rebuild it from the key buffer instead.
>>>>
>>>> However, I must also revert the following hunk in Jim's latest SSE2
>>>> patch in order to get NSLDAP going:
>>>>
>>>> --- john-1.7.7-jumbo-5-RC6/src/NSLDAP_fmt.c 2011-05-23
>>>> 18:51:00.000000000 +0000
>>>> +++ john-1.7.7-jumbo-5/src/NSLDAP_fmt.c 2011-05-24 05:20:43.625000000
>>>> +0000
>>>> @@ -225,7 +225,8 @@ static int cmp_one(void * binary, int in
>>>> static void
>>>> crypt_all(int count) {
>>>> #ifdef MMX_COEF
>>>> - memcpy(buffer, saved_key, 32*MMX_COEF);
>>>> + // 32 byte password (max), plus the 0x80. We need to copy 36*MMXCOEF
>>>> to make sure we get it all.
>>>> + memcpy(buffer, saved_key, 36*MMX_COEF);
>>>> shammx((unsigned char *) crypt_key, buffer, total_len);
>>>> #else
>>>> static SHA_CTX ctx;
>>>>
>>>>
>>>> Jim, was that really a correct patch? I get 1320 found on all platforms
>>>> without that and self test fail with it.
>>>>
>>>> magnum
>>>>
>>>>
>>>> On 2011-05-26 05:45, JFoug wrote:
>>>>> I get a crash on OpenLDAPS. Same type. Only MMX/SSE builds (from
>>>>> cygwin/mingw). It also only crashes on -test not on -test
>>>>> -format=openssha The format_init has been commented out in john.c
>>>>> for a
>>>>> couple of releases, but this is the same type of bug, and really needs
>>>>> to be found.
>>>>>
>>>>> Jim.
>>>>>
>>>>> ----- Original Message ----- From: "Erik Winkler" <ewinkler@...ls.com>
>>>>> To: <john-dev@...ts.openwall.com>
>>>>> Sent: Wednesday, May 25, 2011 10:00 AM
>>>>> Subject: Re: [john-dev] SSE bug still there in Jumbo-5-RC6++
>>>>>
>>>>>
>>>>> Jumbo-5-RC6++ works great on MacOS X for 64-bit build. No issues.
>>>>>
>>>>> On MacOS X using the sse2 build, I get the following error for NSLDAP
>>>>> benchmarking:
>>>>>
>>>>> Benchmarking: Netscape LDAP SHA SSE2 [SHA-1]... FAILED
>>>>> (get_hash[0](3))
>>>>>
>>>>> Now this only occurs when running ./john -test. If I run ./john -test
>>>>> -format:nsldap, it works correctly:
>>>>>
>>>>> ../run/john -test -format:nsldap
>>>>> Benchmarking: Netscape LDAP SHA SSE2 [SHA-1]... DONE
>>>>> Raw: 7837K c/s real, 7837K c/s virtual
>>>>>
>>>>> Not sure why.
>>>>>
>>>>> Erik
>>>>>
>>>>> On May 24, 2011, at 1:58 PM, magnum wrote:
>>>>>
>>>>>> Even after applying all incremental patches posted to the wiki, there
>>>>>> are some problems left in Jumbo-5-RC6:
>>>>>>
>>>>>> 1. Raw-MD4 segfaults for me on linux-x86-sse2:
>>>>>> * Using linux-x86-mmx I saw no problem.
>>>>>> * It segfaults when running "--test"
>>>>>> * It does NOT segfault when running eg. "--test --fo:raw-MD4"
>>>>>> * Test suit does NOT segfault and all 1320 is found
>>>>>>
>>>>>> This led me to believe the problem was in the format running right
>>>>>> before raw-MD4 on a --test run, namely salted-sha1. I did find a bug
>>>>>> in that format (fix included in patch just posted) but that was not
>>>>>> the cause of this.
>>>>>>
>>>>>> 2. NSLDAP has a problem on linux-x86-sse2 and linux-x86-mmx:
>>>>>> Benchmarking: Netscape LDAP SHA MMX [SHA-1]... FAILED
>>>>>> (get_hash[0](1))
>>>>>>
>>>>>> I have no time to investigate further right now.
>>>>>>
>>>>>> magnum
>>>>>
>>>>
>>>>
>>>
>>
>
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.
