JtR style charsets...

[me.scotty]

...would be my first suggestion.
Charset files contain not only the character set, but also frequency statistics.

I can't prove it, but my gut feeling is that this feature improves performance for "incremental" type attacks by at least an order of magnitude. This may allow you to help best insidepro at next year's korelogic...

Another "suggestion" - as a software professional, I find the multiple olcHashcat frameworks (regular, lite, plus) to be somewhat wasteful of development resources. Better to have one framework containing all the "front end" features, and then define a "hashing algorithm" interface which is then implemented for each hash type, allowing for "nesting".
If there are differences (i.e. optimizations) that are needed for different attacks, perhaps the interface can define optional pre and post processing methods.

My 0.02 cents.

[atom]

hmm ok, can you explain how these frequency statistics work?

[me.scotty]

I don't have exact details, but you can find them in the JtR source (charset.c, charset.h).

Intuitively, it seems pretty straightforward.
People have tendencies about which characters they use to construct passwords.
Perhaps they're 100x more likely to use an "s" than a "Z".
So instead of systematically marching through the char set range (i.e. A-Z,a-z), a much more efficient search can be performed using high likelihood characters first, moving to lower likelihood characters later.

JtR has the capability to create such a charset from a dictionary - rockyou, for example. (google)
Note that the rockyou charset is almost 2MB in size, so it must have more than just frequency information - perhaps positional statistics as well.

When using a charset such as this, you get a large number of successful decrypts up front, tapering to lower numbers with elapsed time.

[atom]

in this case, the devil is in the details! sure its more likely to use an "s" than a "Z". but this is just the surface. the algorithm must be much more complex.

you asked for support so you should be able to explain how it works. if not, read the source and then explain me how it works. my job is to hammer it into hashcat.

[me.scotty]

you should be able to explain how it works. if not, read the source and then explain me how it works

I'd really like to, but I can't make heads or tails of it.
The relevant code can be found in the method do_incremental_crack of the source file inc.c, which can be found here http://www.openwall.com/john/g/john-1.7.8.tar.gz

I hope somebody with some aptitude for this can come along and interpret it.
The efficiency of this type of attack, when compared to the simplistic brute-forcing, should not be underestimated!

[atom]

Done with oclHashcat-plus v0.09: https://hashcat.net/forum/thread-1541.html

Thread closed