[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 26 May 2011 09:24:15 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: SSE bug still there in Jumbo-5-RC6++
You need 36 if you want 32 byte PW. BE format.
- static char saved_key[(PLAINTEXT_LENGTH+1)*MMX_COEF];
+ static char saved_key[(PLAINTEXT_LENGTH+4+1)*MMX_COEF];
That change 'should' fix the problem. 0x80 will get put into saved_key[36],
and saved key has 37 bytes. Then, buffer is 80*4*MMX_COEF, the first
64*mmx_coef being the starting buffer, but we only copy in the first part.
Jim.
>-----Original Message-----
>From: magnum [mailto:rawsmooth@...dband.net]
>Sent: Thursday, May 26, 2011 8:48 AM
>To: john-dev@...ts.openwall.com
>Subject: Re: [john-dev] 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.
