Date: Mon, 2 Jan 2006 04:37:54 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: Re: john improvement suggestions - complexity reductions On Sun, Jan 01, 2006 at 11:34:51PM +0000, Radim Horak wrote: > But now that I'm thinking about it, the performance of the custom .chr file was > a way worse than estimated - something must have gone wrong. Would you like the > .chr and .rec file mailed? No, I would not have the time to seriously look into this now, sorry. On the JtR front, making the 1.7 release is currently the primary priority. > Was there any serious error in john 1.6.30? No. > > I had done my testing, too, with alpha.chr vs. all.chr, -- as expected, > > all.chr would outperform alpha.chr after some time (way earlier than the > > alpha.chr keyspace would be exhausted). > > I'm still puzzled about this. I think it greatly depends on the ratio of pure > alpha passwords in the whole sample and on distribution of the non-alpha chars > in the sample. Yes. > If more than 90% of the passwords would fall outside of alpha. > chr, than I believe all.chr is better, if more than 90% of passwords fall within > alpha.chr, than I'd certainly start with alpha.chr. Yes. The problem with the latter case is that if you start with alpha.chr, but then switch to all.chr, you would be having John try many candidate passwords for a second time. Using all.chr with a "non-alpha" external filter is a workaround, but the filter would eventually be causing John to skip all-alpha candidate passwords which it hadn't tried before (that is, those the interrupted alpha.chr run didn't cover). What you really would need is an all.chr tailored to your passwords sample - then you would have no need to artificially limit the keyspace you let John search initially. Unfortunately, you need a substantial number of passwords already cracked in order to generate a reasonable .chr file. > Also the all.chr should be > better if tested against the same sample it was created from. Indeed. But such a test would not be fair, and is intentionally not what John is optimized for (I could easily have it re-crack all the same passwords almost instantly, but that would make the order in which candidate passwords are tried less optimal for real-world runs). I've been doing such tests, but only to spot possible bugs, etc. > I think that on unknown sample the statistical mismatch increases the all.chr > keyspace way faster than that of alpha.chr. I understand what you're trying to say, but that statement is not quite correct as written (the keyspaces are fixed). Yes, if the passwords being cracked are very different from those that were used to generate the .chr files, then artificial keyspace reductions could help achieve a higher success rate. This does not only apply to all.chr vs. alpha.chr, but also to MinLen/MaxLen and CharCount settings. > What was approximately the % of alpha keyspace, where it was outperformed by > all.chr in your test? It's been some years since I've done that test so I do not have the exact numbers, but I've just tried calculating this percentage based on the approximate real time it's taken, the c/s rate, and the number of salts loaded. It's under 1% of the alpha.chr keyspace (26 lowercase letters, lengths up to 8). There were a lot of passwords with numbers (and even all-numeric ones), so alnum.chr would have performed a lot better than alpha.chr did. I might repeat this kind of a test some time after John 1.7 release. > If I'd like to test the effectiveness of .chr files on already cracked > samples, is there some _easy_ way to do it? (with --stdout?) Well, I'm afraid not. You could have John crack those hashes again, but that would involve actually hashing all candidate passwords, even though this could have been avoided in such a test. Yes, you could use --stdout, but then you'd need to develop another tiny program (e.g., a Perl script) to do the comparisons. If you really want to have this test run fast, you need to code a custom "format", where crypt_all() would be a no-op and cmp_*() would do direct comparisons. I've been thinking to include this functionality (plaintext passwords "cracking") in John, but too few people would need it. -- 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 Was I helpful? Please give your feedback here: http://rate.affero.net/solar
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.