04-11-2015, 07:53 PM
FYI, the reason for the initial best64 was to generate enough material that, when used as an amplifier for fast hashes, it's nearly as fast as the theoretical maximum performance. Of course this totally changed in comparison to the currentl oclHashcat version.
Sorting by occurance, or by efficiency, is some idea that I really like. The dive.rule or the generated*.rule are ordered the same way. However from what I've seen people don't do this kind of stuff. It's the opposite they even do stuff like $ cat rules/* > all.rule
If the goal for the challenge is to find the best XX for slow hash processing we'd typically end up with the usual suspects like $1, $1$2$3 etc. I mean, this propably makes sense as those are really the best rules but maybe not what we are looking for.
Finally the more important question than the one how many rules we want is how we do it and which reference hashes we use.
Sorting by occurance, or by efficiency, is some idea that I really like. The dive.rule or the generated*.rule are ordered the same way. However from what I've seen people don't do this kind of stuff. It's the opposite they even do stuff like $ cat rules/* > all.rule
If the goal for the challenge is to find the best XX for slow hash processing we'd typically end up with the usual suspects like $1, $1$2$3 etc. I mean, this propably makes sense as those are really the best rules but maybe not what we are looking for.
Finally the more important question than the one how many rules we want is how we do it and which reference hashes we use.