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.