[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 1 Jan 2006 23:34:51 +0000 (UTC)
From: Radim Horak <yesbody@...nam.cz>
To: john-users@...ts.openwall.com
Subject: Re: john improvement suggestions - complexity reductions
Solar Designer <solar@...> writes:
> I'd like you to clarify a few things:
>
> 1. When you say the success rate was 20 times better, you're comparing
> the first month of running against your custom "wordlist" against a
> non-first month of running against your custom alpha.chr, correct? The
> .chr file's success rate would have been better on its first month,
> correct?
Generally yes, but it is more complicated. I was testing it with the original
alpha.chr - don't remember how long exactly, but certainly less than month. Also
the custom wordlist's success rate would have been better if I'd run it first.
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? Was there any serious error in john 1.6.30?
I know that the comparison is not fair, but I don't have resources for testing.
The numbers given should be taken as rough measurements, valid only for my
sample.
> 2. Did you do any comparisons against the alpha.chr and/or all.chr
> supplied with John 1.6 instead of against your custom alpha.chr?
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. 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. Also the all.chr should be
better if tested against the same sample it was created from.
I think that on unknown sample the statistical mismatch increases the all.chr
keyspace way faster than that of alpha.chr.
What was approximately the % of alpha keyspace, where it was outperformed by
all.chr in your test?
> > My tests with limited length incremental mode with all.chr shows that for
about
> > 90% of passwords it was needed 25% of total keyspace cracking-time and there
> > were passwords cracked after 50% of total keyspace cracking-time.
>
> I'm not sure what specific test you're referring to here, but I'll try
> to guess. You've reduced MaxLen making it low enough that you can
> search the keyspace exhaustively, and you actually did that, correct?
> Now, you're complaining that it's taken as much as 25% of the total
> cracking time (that is, the time needed to exhaustively search the
> reduced keyspace) to crack 90% of the passwords in your sample. OK,
> this is quite realistic.
90% of all passwords, that were cracked within this specific incremental test
with MinLen=5,MaxLen=5 and all.chr from orig. john 1.6.
> Now, if you reduced your keyspace to that of alnum.chr (36 different
> characters, no uppercase ones), would you crack those 90% at all, or
> would more than 10% of the passwords in your sample fall outside of the
> alnum.chr keyspace?..
I would not crack those 90% since I was running it _after_ exhaustively
searching the alnum.chr keyspace. It was not run to be compared with alnum.chr
but to see the effectivity within all.chr. The bare possibility of comparing
these two charsets came to my mind only with your reply. However, there were
only less than 8% of passwords in my sample, that would fall outside of alnum.
chr.
> That's true, but the same applies to alnum.chr, -- unless you would
> actually search that smaller keyspace exhaustively.
The idea is that the bigger part of keyspace is searched, the less it is prone
to falling outside the optimized statistics of .chr file.
> > - with all keyspace: some rather simple passwords are hard to crack, because
> > they are concatenated from a few small words with (or without) spaces
between
> > them. This could be solved by smarter and more careful generation of
wordlists
> > from e-texts.
>
> Yes, a double-wordlist mode to be used with really small wordlists could
> make some sense.
>
> Alternatively, given that the input wordlists would need to be really
> small, such double-wordlist file could be pre-generated with a trivial
> Perl script.
Well, I would put emphasis on the "really small" 'cause the keyspace is geting
bigger _very_ fast this way. I think, that in relying on existing e-texts, the
number of combinations and the resulting keyspace would grow notably slower.
> Yes, and you can definitely crack more passwords by using these tricks
> _after_ you've been cracking with all.chr for a while. But if you use
> them _instead_ of the .chr files (that is, not use John's "incremental"
> mode at all), then you may well crack fewer password hashes because of
> your being "smart" like that.
I fully agree with this point. The propositions were directed at the state,
when no more passwords are easily cracked. Moreover the psw. cracking is not an
exact science so the recomended approach would differ in various psw. policies,
hashes and samples.
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?)
Finally big thanks for your thorough reply
-Radim
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.
