Date: Sun, 11 Jan 2009 05:39:50 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Clarification desired on modifying incremental mode to handle 9 chars On Sat, Jan 10, 2009 at 04:20:38PM -0600, Steve Bergman wrote: > I'm just getting to know john and am wanting to try out cracking length 9 passwords. And I want to confirm that I'm doing this right. Please note that you don't need any modifications to have JtR try such passwords with modes other than "incremental". > In this (relatively old) thread: > > http://marc.info/?t=118342345400004&r=1&w=2 BTW, this is one of many messages referenced from this wiki page: http://openwall.info/wiki/john/mailing-list-excerpts > Solar Designer explains: > > >The above example is for lowercase letters. I've actually tested it by > >first generating a fake john.pot from all.lst: > > > > zcat all.gz | sed 's/^/:/' > john.pot > > > >Then I generated a new .chr file with the patched build of JtR 1.7.2: > > > > ./john --make-charset=alpha13.chr > > I have a few questions: > > If I am only going to 9 chars, and thus CHARSET_SCALE does not change, do I really need to generate a new .chr file? Yes, you do. The check in src/inc.c is strict - your patched build of JtR will refuse to load old .chr files - and removing this check would be wrong (other changes to the code would be needed as well). Also, .chr files encode sorted lists of characters for each character position separately, so the old files simply have no data for length 9. There are fallbacks to non-length-specific data, but like I said other changes to the code would be needed for you to get that far with a .chr file inconsistent with compile-time settings of JtR. > If so, is the method described above the best I am going to do without some source of real life nine character passwords? It should be about the best you can do, yes. Since the resulting .chr file might be worse than the bundled ones for lengths 1 to 8, you could want to use it (and this build of JtR) for length 9 only (set MinLen and MaxLen to 9). > Would it make sense, and be better, to run the list through the default wordlist mangling rules first and use the result to generate the .chr? Yes, it makes sense. Whether it would be better or worse depends on your (unknown) passwords (and which list resembles them more closely), on how long you intend to run JtR against them, and on the candidate passwords per second rate (which depends on hash type and number of different salts). It might turn out that without the rules you get a higher success rate initially but then it drops, whereas with the rules you get a lower success rate but it does not drop as badly for a long time (so you may get more passwords cracked after long enough). On the other hand, you might never run JtR for long enough to see the success rate start to drop in the first case. You may run it in both ways (different .chr files) on two CPU cores. Indeed, this will be suboptimal as many candidate passwords will be tried twice, but it will be an interesting experiment. You may have your remaining two cores try lengths 1-7 and 8 with one of the bundled .chr files (perhaps with all.chr) for comparison. Then post your results in here - number of passwords cracked by each process, say, after 1 hour, 1 day, 1 week, 1 month, number of password hashes and different salts, c/s rate (as reported while cracking and as reported by "--test" separately). My expectation is that you'll crack very few length 9 passwords in this way, given that you're dealing with slow hashes and the search space for length 9 is substantially larger. You'd crack more passwords total by letting the "length 9" cores try more length 1-8 passwords. > Presumably, there is a wise rationale for limiting john to 8 rather then 9 characters by default. If the character range is not limited by increasing to 9, why is 8 the default? Actually, I regret not upping the compile-time setting to 9 shortly before the 1.7 release. I should have probably done that as I re-generated the .chr files at the time anyway. I did not have to actually include data for length 9, but having the compile-time limit set higher would allow for my bundled .chr files to co-exist with files that JtR users could generate themselves for length 9. > (That last might be rephrased as "What hole am I getting ready to fall into"? ;-) Just non-optimal use of CPU time, I guess, as you're unlikely to run JtR for long enough, given your slow hashes, for attacking of length 9 in this way to become more effective than attacking shorter lengths. I'd be curious to learn of your actual results. Thanks, Alexander -- To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply to the automated confirmation request that will be sent to you.
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.