[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <002201cc1bad$a8806260$f9812720$@net>
Date: Thu, 26 May 2011 09:03:15 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: SSE bug still there in Jumbo-5-RC6++
A better fix is to keep PLAINTEXT_LENGTH to 31, but if there are longer
passwords, should they be checked also? The way it was (Plainlen=32 and
memcpy=32), it would work just like plain=31, but will 'test' 32 char
passwords, but never find them.
I will give the code another check over.
Jim.
>-----Original Message-----
>From: magnum [mailto:rawsmooth@...dband.net]
>Sent: Thursday, May 26, 2011 8:23 AM
>To: john-dev@...ts.openwall.com
>Subject: Re: [john-dev] SSE bug still there in Jumbo-5-RC6++
>
>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.
