[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <9B6572B8-14EA-42D4-BE0E-157833092DF4@patpro.net>
Date: Mon, 11 Jan 2016 16:34:13 +0100
From: patpro@...pro.net
To: john-users@...ts.openwall.com
Subject: Re: format-all-details -> Max. password length in bytes
On 11 janv. 2016, at 15:52, Frank Dittrich <frank.dittrich@...lbox.org> wrote:
> For some formats, a developer could look into the problem and see what performance impact increasing the max. password length would have.
>
> Salted SHA1 currently supports a max. salt size of 16 bytes:
> salted_sha1_common.h:13:#define MAX_SALT_LEN 16
>
> The max. password length is defined so that just a single SHA1 block needs to be computed per candidate:
> salted_sha1_fmt_plug.c:58:#define PLAINTEXT_LENGTH (55-MAX_SALT_LEN)
>
> So, if all your hashes do have a salt length < 16 bytes, you could use a larger max.password length for salted-sha1 and salted-sha1-opencl by decreasing MAX_SALT_LEN.
It makes perfect sense, a single byte over 55-MAX_SALT_LEN would then require a second SHA1 block computing, doubling (?) the time needed for each test. That's a good reason to stop at 55-MAX_SALT_LEN.
And I'm quite happy that my own passwd in the dump is way longer than 55-MAX_SALT_LEN ;)
> OTOH, dynamic_24 and dynamic_25 are quite similar to salted-sha1.
> One of these dynamic formats computes SHA1($p.$s), the other SHA1($s.$p).
> Both of them do have max. password length of 110 and a salt size of 64, but you can see that the speed of these formats is considerably slower.
it's slow enough with regular Salted SHA1, and I can't do GPU to gain horse power. Moving to something slower with a larger haystack does not sound so appealing.
Thanks a lot Frank and Rich for your answers. It helps me a lot understanding the way JtR works.
regards,
pat
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.
