Date: Fri, 30 Jun 2006 01:21:01 +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? On Thu, Jun 29, 2006 at 06:50:51PM +0000, Phantom wrote: > So, regarding the first example, It would help if you learn to quote relevant bits of context. ;-) > 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. > when the rules have a possibility "creating" duplicate candidate words. That is irrelevant to the ordering of rules - but it is a reason to use the M and Q commands as appropriate. > That way the Q can "cover" more than one rule/line? All rule commands, including Q, are a part of the rule they're specified in only. However, when writing a rule, it is wise to take into consideration other rules that you have in the same ruleset. > I was under the impression that the Q and M switches were only applied to the > rule/line in which they appeared... That's correct. > So how does one decide in which rules to include a Q in order to avoid > as many duplicates as possible You have to think and be smart. I'm afraid that I can't provide a better answer. Even if I would come up with step-by-step instructions, those would resemble an implementation of AI on top of your brain. ;-) > and how does Q's affect the spreed of which JTR generated the new > candidate passwords? They have a certain processing cost, like almost all other rule commands do. They also cause JtR to reject some candidate passwords that it has already spent time on - but if those candidate passwords would be duplicates, it is good to reject them before they're processed further anyway. 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. -- 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
Powered by Openwall GNU/*/Linux - Powered by OpenVZ