(04-21-2021, 02:36 AM)Chick3nman Wrote: "...the overall performance increase would take off a minimum of 5% of time taken..."
This is where other optimizations will cause FAR larger increases, and i feel like the penalty of late rejections are actually fairly likely to cause a overall performance decrease. Consider what happens when a word of normal length(6-8) meets a rule(ZY) that couldn't possibly produce a short enough plain to fit into the buffer? Well it doesn't even make sense to process that rule at all if its clearly not going to work, right? So we can throw that rule completely out before we even get to the kernel. What if a rule is very unlikely to create a candidate that fits, unless words are very short? We can also throw that rule completely out, saving you (throw away) * (words in wordlist) candidates immediately, and only costing you the time it takes to parse your rule file and trash obviously useless rules. In fact, this is something that i was looking into recently because the way we are handling these rules now leaves some of them in and seemingly creates duplicate words where unnecessary or does what you are looking to do and generates a candidate that we have to reject in the kernel. Just implementing something like that would likely trash enough rules from the 360,000 list off the bat that it'd save you that 5%+ you are after.
That's definitely true, so I focus mainly on analysis and forcing out some of the left overs that have been public for years (md5 ntlm and sha1 + dash usually) which is extremely time consuming and overall just willing to try and test whatever ideas I can to bring a little more speed in.
The reason I run such a large rule set - I run it against around 500gb worth of dictionaries and always run with the same rules using(-debug-mode=1 --debug-file=) so I can analyse the rules.
I have a more optimal rule file however that's for testing on small wordlists due to how optimized it is.
I mean we all want the same end results right?
Optimization! No matter the cost.