[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
