[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAB-fiYSaKW_TQsXJMxCzQr7gR+1ZPw9sLxto-nG0gHwdKu6bcA@mail.gmail.com>
Date: Mon, 11 Feb 2013 14:28:30 -0500
From: Lex Par <ziptied@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking SHA1 with some knowledge of password
Nevermind, I think I found my answer. by using mpi (IE: mpirun -np 20
./john ) I am seeing 21000k c/s.
Thanks
On Mon, Feb 11, 2013 at 12:39 PM, Lex Par <ziptied@...il.com> wrote:
> I spent a good portion of the morning "attempting" to optimize Jtr to
> crack a SHA1 hash. Thanks you guys, I've been able to get my dynamic
> format, but the computations per second leave something to be desired
> (1800k c/s). I tried recompiling it with the MPI parallel suport enabled
> (per the wiki), but saw no real difference performance.
>
>
> Any suggestions on how to optimize jtr to utilize more processor power?
> any suggestions on how to run jtr to be more effective (currently running
> it in both increment mode and normal/non-specified mode). I have decent HW
> (R710, 24 cores, etc), any suggestions.
>
>
> Thanks!
>
>
>
>
> On Fri, Feb 8, 2013 at 9:26 PM, Lex Par <ziptied@...il.com> wrote:
>
>> Thanks! I've learned more in this exchange, than weeks of playing with
>> jtr !
>>
>>
>> On Fri, Feb 8, 2013 at 6:09 PM, jfoug <jfoug@....net> wrote:
>>
>>> There are going to be limitations within JtR.
>>>
>>> I did look at code, and it appears that the x86 (i.e. non SSE) has
>>> internal
>>> buffer lengths in dynamic that are PLAINTEXT_LENGTH_X86+96
>>> PLAINTEXT_LENGTH_X86 is set to 124 bytes, and 1 byte needed for NULL.
>>> So,
>>> in theory, you could encrypt strings (internally within dynamic) up to
>>> 219
>>> bytes, without crashing JtR. I just tested with a format that had 80
>>> characters appended, and 110 character prepended. The length being
>>> encrypted for the password openwall, is 198 bytes, well within this
>>> apparent
>>> 219 bytes max length in dynamic, but also well past JtR's 125 byte
>>> password
>>> length. Now, the password was really only 8 bytes long (openwall). The
>>> constants took up the other 190 bytes. With this 190 byte 'const',
>>> dynamic
>>> can only handle passwords up to 29 bytes.
>>>
>>> Here is this format. It also shows how to force dynamic to fall back to
>>> OpenSSL, and NOT use SSE.
>>>
>>> [List.Generic:dynamic_1051]
>>> Expression=xxxSHA1($p)yyy
>>> Flag=MGF_SHA1_40_BYTE_FINISH
>>> Flag=MGF_NOTSSE2Safe
>>> MaxInputLen=29
>>> Func=DynamicFunc__clean_input
>>> Func=DynamicFunc__append_input1_from_CONST1
>>> Func=DynamicFunc__append_keys
>>> Func=DynamicFunc__append_input1_from_CONST2
>>> Func=DynamicFunc__SHA1_crypt_input1_to_output1_FINAL
>>>
>>> Const1=012345678901234567890123456789012345678901234567890123456789012345678
>>> 90123456789
>>>
>>> Const2=012345678901234567890123456789012345678901234567890123456789012345678
>>> 90123456789012345678901234567890123456789
>>> Test=$dynamic_1051$546de0d2e256cb51f96a06ff54a08994f95da5d9:openwall
>>>
>>> And here shows building this test hash, and test runs of the 1050, and
>>> 1051
>>> types (to see the difference in speed).
>>>
>>> $ echo -n
>>>
>>> "012345678901234567890123456789012345678901234567890123456789012345678901234
>>>
>>> 56789openwall012345678901234567890123456789012345678901234567890123456789012
>>> 34567890123456789012345678901234567890123456789" | sha1sum
>>> 546de0d2e256cb51f96a06ff54a08994f95da5d9 *-
>>>
>>> $ ./john -test=5 -form=dynamic_1051
>>> Benchmarking: dynamic_1051 xxxSHA1($p)yyy [32/32 128x1]... DONE
>>> Raw: 1701K c/s real, 1701K c/s virtual
>>>
>>> $ ./john -test=5 -form=dynamic_1050
>>> Benchmarking: dynamic_1050 xxxSHA1($p)yyy [128/128 SSE2 10x4]... DONE
>>> Raw: 5602K c/s real, 5601K c/s virtual
>>>
>>>
>>> From: Lex Par [mailto:ziptied@...il.com]
>>> >
>>> >Theoretically, if I were to create a function the pads an input (ie
>>> >password) with 120 bytes, then hashes the 120+password input to produce
>>> the
>>> hash, this would not be crackable via the 128 byte limit (since our hard
>>> limit not using the optimizations is somewhere in the 90~)?
>>>
>>>
>>
>
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.
