[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB-fiYTXKDMjW1NQSw_T5tkYvmiAHsTZbcfrp44ri+VhYejqiA@mail.gmail.com>
Date: Mon, 11 Feb 2013 12:39:10 -0500
From: Lex Par <ziptied@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking SHA1 with some knowledge of password
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.
