[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB-fiYRG9anZU2Mx4RWtgcoVCpVmB7QS7-BFEhTcLoPzimf2cQ@mail.gmail.com>
Date: Fri, 8 Feb 2013 21:26:24 -0500
From: Lex Par <ziptied@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking SHA1 with some knowledge of password
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.
