[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAB-fiYRgbaOB55HrP3uG6RH6DHVc+UNgYt85_fuCSjrhNJg01g@mail.gmail.com>
Date: Fri, 8 Feb 2013 17:50:22 -0500
From: Lex Par <ziptied@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking SHA1 with some knowledge of password
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~)?
On Fri, Feb 8, 2013 at 5:35 PM, jfoug <jfoug@....net> wrote:
> From: Lex Par [mailto:ziptied@...il.com]
> >This might be a silly question, but why is there a 55 byte max?
>
>
> Not a silly question at all.
>
> the short answer:
> the 19 byte limit (in the format I provided), is due to requirements from
> the optimizations that are being used.
>
>
> The full answer:
> SHA1 (and MD4/MD5, etc), all work on 64 byte blocks. However, there are 9
> 'extra' bytes needed. The bit (full byte) right after the data being
> encrypted is set to a 1 (so that byte gets set to a 0x80). Then the last 8
> bytes of the last block (there can be more than 1 block), is set to hold
> the
> number of bits being encrypted, as an 8 byte integer value. Thus to make
> things fit into 1 SHA block, you can have 55 bytes of password, followed a
> single byte 0x80. Then there are still 8 bytes left, which is just enough
> to
> place the length of the bit stream. Anything over 55 bytes, will not fit
> into a single SHA1 buffer. Encrypting 56 bytes with SHA1, requires 128
> bytes of buffer (2 64 byte buffers) to be encrypted.
>
> Within our SSE code in the dynamic format we can only encrypt a single
> block. More 'can' be encrypted, but causes more code, and another full
> SHA1
> on that block. This extra code, slows down most 'common' searches for
> passwords. It is very uncommon, for passwords to go past this 55 byte
> threshold, thus we have made an assumption that only a single block will be
> allowed, which removes this extra code overhead. If you really need to do
> passwords longer than this, then it is best to leave this format as is
> (with
> 19 char password max), and then make another format, that uses the dynamic
> flag: MGF_NOTSSE2Safe This will force that format to NOT use SSE, but
> revert to using slower OpenSSL library to do the SHA1. That will allow up
> to 96 (or 125??) bytes to be in the password. So, if there are 36 bytes
> used, you can for sure handle up to 60 byte passwords. However, It would
> be
> best to ONLY use that format to check passwords between 20 and 60 bytes,
> using the faster version to process passwords from 0 to 19 bytes long. In
> real world situations, 19 byte passwords make up almost ALL of them. there
> are a few that go longer than that (often these longer passwords ARE the
> high value accounts).
>
> Jim.
>
>
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.
