[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20060630153537.GA6798@openwall.com>
Date: Fri, 30 Jun 2006 19:35:37 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Re: rules - Q vs M and their effects on speed?
I suggested:
> > It would help if you learn to quote relevant bits of context.
On Fri, Jun 30, 2006 at 06:54:15AM +0000, Phantom wrote:
> I usually do that, but in this case I thought that you would be able to
> easily understand what I was referring to :)
Indeed, but you're forgetting that this mailing list exists primarily
for its other subscribers and for those browsing the archives - not just
for the two of us.
> > > it does make a difference in which order rules are entered in the
> > > conf/ini file
> >
> > Yes - because you want rules that happen to produce a higher success
> > rate tried first - but this has nothing to do with the M and Q commands.
>
> Ok, so basically that is because the sooner a password is cracked, the better
> because then the follwing rules won't waste energy on the same hashes?
Correct. Perhaps even more importantly, the users of John typically
want the weakest passwords cracked earlier.
> >For example, the following two rules:
> >
> ># Try words as they are
> >:
> ># Lowercase every word
> >-c lQ
> >
> >might produce fewer duplicate candidate passwords than:
> >
> ># Try words as they are
> >:
> ># Lowercase every word
> >-c l
> >
> >would. That's because some input words are already all-lowercase, so
> >converting them to lowercase does not change them. The "Q" in the first
> >example would reject words that are unaffected by the conversion.
> >(Alternatively, words could have been checked for containing uppercase
> >letters prior to the conversion to lowercase.)
>
> Why do you include two lines here, if the Q does not cover more than
> one line?
I've included two rules in the example because it only makes sense with
both of them - despite the fact that John processes those lines
independently from each other.
> I understood it as lowercase words that are tried on the first rule ":"
> are not affected by the lowercase conversion in the second rule,
> which is why you included the Q in the second rule - to avoid the
> already tried lowercase words from the first rule to be "converted" by
> the second rule?
Correct.
(More precisely, the already-lowercase words are "converted" to
lowercase by the second rule anyway, but they're rejected with the Q
command and thus not processed any further.)
> > You appear to think that the only reason to not use Qs is to avoid the
> > processing costs associated with them. This is not the case. The
> > primary reason why John does not imply a Q after each rule is that doing
> > so would reject candidate passwords that are _not_ duplicates of any
> > others. Thus, Q should be used with care.
>
> Yes, I am beginning to see that now, was just curious as to how big an impact
> on speed they had-
The processing cost of the M and Q commands themselves is usually
negligible (except with really fast saltless hashes - but running a
wordlist against those is fast anyway). When all candidate passwords
that Q rejects are in fact duplicates, the use of Q is appropriate
despite the fact that the reported effective c/s rate is reduced.
> Please consider the below rules:
>
> >8'7
> >7'7
> >8'6
> >7'6
> >6'6
> >7'5
> >6'5
> >5'5
This combination of rules doesn't make sense. You can simplify it to:
>7'7
>6'6
>5'5
With your sample wordlist, this reduced ruleset produces 19 instead of
46 candidate passwords - including the same 14 unique ones.
> If using the "wordlist" below, I have tried placing Q's and M's at the end on
> some of the rules, all of the rules, before and after the ', but I still
> can't avoid getting duplicate words as a results of the above rules and the
> below wordlist - please advice?
Well, the M/Q approach is not supposed to eliminate all duplicates in
all cases. It can only reduce the number of duplicates in some cases.
> <Wordlist>
> bananas
> bananasing
> Bananas
> Bananasinger
> Bananasingerer
> oranges
> orAnges
> orangesandapples
> Orangesandapples
> orangesandapplessuck
With a wordlist like the above, you will have many duplicates as a
result of your having similar input words - not as a result of applying
multiple rules. The M/Q approach only works in the latter case.
> I get the same 46 words as output wether I use Q (and M) or not....
Well, Q is almost useless this time.
However, by removing redundancy from your ruleset, we've reduced the
number of candidate passwords it produces to 19, with 14 unique ones.
If you want to completely eliminate duplicates, you need to use the
"unique" utility, which is a part of JtR. Please refer to EXAMPLES
in the documentation. Note that with fast saltless hashes, it might
not be worthwhile to spend CPU time on eliminating all duplicates.
--
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
--
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.
