[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20050515011431.GC28638@openwall.com>
Date: Sun, 15 May 2005 05:14:32 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: NT hast maxlen questions...
On Sat, May 14, 2005 at 02:02:45PM -0700, Whom Ever wrote:
> Ok, I found the params.h file but not sure how to
> adjust. I mean what if I wanted to check 16 character
> passwords? Then I'd have 95^16 which is >> 2^64 even
> if you adjust the SCALE term. And if you go ahead and
> just make the lenghth 16 and violate the 64 bit
> requirment, it appears the *.chr files no longer are
> appropriate. So maybe NT hases are split?
No, NT hashes are not split.
The *.chr files assume very particular CHARSET_* parameters. Almost
any change to these parameters invalidates your old *.chr files. The
exact check is in inc.c: do_incremental_crack(), and it is as follows:
if (feof(file) ||
memcmp(header->version, CHARSET_VERSION, sizeof(header->version)) ||
header->min != CHARSET_MIN || header->max != CHARSET_MAX ||
header->length != CHARSET_LENGTH ||
header->count > CHARSET_SIZE || !header->count)
inc_format_error(charset);
You got to have sufficient statistical information in your john.pot in
order to generate sensible *.chr files. If you want to cover lengths
beyond 8, it is highly desirable that you have lots of such long
passwords in your john.pot already. And this is tricky to achieve
since these passwords are both rare and hard to crack. While you
might get away with processing a wordlist instead, that will be far
from optimal and you won't get characters which never occur in the
wordlist (you can add these with "Extra = ..." in the "incremental"
mode section, though, -- but then they would be low-priority and thus
John won't try them until it exhausts all other possibilities for a
given length). Slightly better results may be achieved with this
dirty trick:
john -i -stdout | sed 's/^/nohash:/; 10000000q' >> john.pot
john -make=new.chr
(This needs around 150 MB of disk and memory; decrease the number in
the sed invocation for smaller systems.)
This re-uses the information from the existing all.chr, albeit not
fully and not in the most optimal way. (Yes, it could be possible to
develop some code to "expand" *.chr files to greater lengths, or to
have inc.c do the equivalent of that on the fly.)
Now, as it relates to the 64-bit limitation: yes, not all reasonable
settings will fit in under the limitation. And it is not wise to
ignore it since the resulting *.chr files will result in your
candidate passwords being tried in an order that may be very far from
optimal (up to the point where you won't get anything cracked). (The
current versions of John won't even let you ignore this overflow,
unless you'd patch the check out.)
However, please note that you would never exhaust the 64-bit keyspace
in practice. The only reason you could possibly want to have
CHARSET_SIZE and CHARSET_LENGTH set in a way which makes the keyspace
exceed 64 bits is to be able to try both shorter passwords with a
large charset and longer passwords with a small charset. You won't be
trying longer passwords with a large charset in any reasonable amount
of time anyway. This leads us to the following workaround:
For lengths up to 8, just use a default build of John with the supplied
all.chr. For lengths 9 through 16, use another build of John with
CHARSET_SIZE = 15, CHARSET_LENGTH = 16, CHARSET_SCALE = 2. You can
further improve this by introducing a third build, e.g. for 9-12. If
you can, keep CHARSET_SCALE higher in order for the fixed-point math
to be more precise.
Yes, this is something which I might need to improve in future
versions of John. However, even if I do, there're practical reasons
why uses of "incremental" mode on passwords longer than 8 will be
substantially less efficient than they are on lengths up to 8.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598
http://www.openwall.com - bringing security into open computing environments
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.
