[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Aug 2011 20:08:46 -0500
From: "JimF" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: Re: .include "other_rule_group" (a wish list item)
From: "Aleksey Cherepanov" <aleksey.4erepanov@...il.com>
> Am I right when think that it is like to run John with the first rule
> and then to run John with the second rule (that would be pulled in)?
The way I have implented this, it is rule1 + rule2 (appended). Actually,
another rule set can be inserted at any location within another rule. So
you could have 3 or 4 rules, then an include of another rule set, then still
have 15 other rules following.
So if this is what you had:
[List.Rules:RulesA]
A
B
.include "RulesB"
C
D
[List.Rules:RulesB]
a
b
c
d
You would end up with these rules:
A
B
a
b
c
d
C
D
> Maybe it would be better to run this using key like: -rules:ruleA,ruleB .
>
> I could imagine that it could be generalized to two operations on
> rules: append and combine.
>
> For instance we have two rules:
> [List.Rule:ruleA]
> A
>
> [List.Rule:ruleB]
> B
>
> where A and B are some rules.
>
> So ruleB appended to ruleA would look like
> A
> B
>
> And ruleB combined with ruleA would look like
> A B
I really like this. There are many rule sets where RulesA * RulesB would not
be productive at all, but there are other sets where this could be SUPER
productive. For instance, making small rules like:
[List.Rules.AppeSpecial1]
$[!@...^&*()-_]
[List.Rules.AppeSpecial2]
$[!@...^&*()-_]$[!@...^&*()-_]
[List.Rules.AppeNum1]
$[0-1]
would be wonderful rules to be able to 'combine' with other rules.
> The last case could be achieved now using John in such way:
> john -ru:ruleA ... -stdout >t
> john -ru:ruleB -w:t ...
>
> However really it would give following combination:
> A M B
> where M is a memorization rule command.
>
> Maybe this could be done with key too: -ru:(ruleA+ruleB)*ruleC
> where + is used to append rule and * to combine rules. However such
> syntax needs quoting for shell that is problem like with braces quoting
> with md5_gen(n) format.
I would propose that we implement the append, using the #include syntax I
have started. Then add something like:
-rules=Rules1.Rules2 (or a comma, etc), to allow the combine to happen.
Combine can be very dangerous, in the fact that it can generate millions of
rules and there are other, many other things that need to be planned on how
to implent. The things off the top of my head, I can see as hurdles for
combined is:
1. huge number of combinations. rules with 10, combined with rules of 25
combined with rules of 120 gives 30k rules.
2. Elimination of dupe rules.
3. Reduction of rules, simple reduction, and possibly more complex
reduction.
4. Optimization of rules. Note, if 3 and 4 are done, then elimination
should likely be done after doing those 2.
But the concept if we can implement it properly, certainly sounds like it
could well be a winner.
Jim.
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.
