04-21-2021, 02:17 AM
(04-21-2021, 02:14 AM)Chick3nman Wrote: "The main reason for this which you can test yourself is just file in with some rules to make LONG passwords then run it with optimized kernels - and compare the speed difference with and without."
I'm not sure what you mean here
With and without the rules? Because that will always benefit the rules from a workload perspective, and will be slower than if you didn't generate the failing words to begin with but kept the same rule related workload. With and without optimized kernel also doesn't make sense, because optimized kernels are doing far more than simply rejecting words because they are too long, that's just a side effect of the optimization. Long passwords, beyond the point of rejection, in large numbers will incur a penalty to your cracking speed, up to the point where no candidates are being hashed in most work groups. At that point, you may see some speed return but it will not be ideal or likely very performant overall.
With 360,000 rules you are well out of reasonable territory for a manageable keyspace, you are correct. That rule set is unreasonably large for an efficient attack setup, but to each their own, i have played with similarly large rule sets a fair amount but never for a normal attack.
Sorry I misspoke as I was trying to catch you while you are still online, apologies.
You are correct in that the optimization impacts other areas, but I still believe the overall performance increase would take off a minimum of 5% of time taken which is more than enough reason to use it.