Do not try to write --keyspace yourself

[royce]

Yeah, the naming cat is probably already out of the bag.

I've clarified the FAQ section to make it very clear that hashcat --keyspace is specifically for distributing work, and does not directly correspond to literal keyspace. If it was news to me, it's likely to be news to others.

[sjohnny1972]

Thanks for the references and explanation! I'm still interested to find out how this works exactly.

Related to my first question on base:mod of the --help output:
"[Amplifying is accomplished] by splitting attacks up into two loops: a base loop, and a modifier loop. The base loop is executed on the host and contains the initial password candidates. The modifier loop is executed on the compute device, and generates the rest of the candidates from the initial candidates on the device directly. The modifier loop is our amplifier, that's where our acceleration comes from." https://hashcat.net/forum/thread-5287-po...l#pid28724


A minimum working example:

Code:

$ ./hashcat -m 0 -a 0 example.dict -r rules/best64.rule --keyspace
129988
$ ./hashcat -m 0 -a 0 example.dict  --keyspace
129988

According to the FAQ 129988 is correct as the rules are never taken into account for -a 0, which seems strange.
The calculation of 'hashcat legacy' seems to make more sense for -a 0 as the "number of words in wordlist multiplied by number of rules in rule file"

Maybe atom could clarify why this changed?

[undeath]

Yeah, the naming cat is probably already out of the bag.

The old options could stay but be left undocumented in --help and a differently named switch with the same effect be introduced. It would make things less confusing for new users.

[epixoip]

According to the FAQ 129988 is correct as the rules are never taken into account for -a 0, which seems strange.
The calculation of 'hashcat legacy' seems to make more sense for -a 0 as the "number of words in wordlist multiplied by number of rules in rule file"

I can't really explain it any better than I already did in the thread you linked to. I guess I can try to expand upon it.

In order to accelerate fast hashes, we have to actually give the GPU some work to do. Generating the passwords on the host and sending them to the device(s) for hashing isn't anywhere near enough work, see for yourself by using e.g. MD5 + stdin. We give the GPU the additional work it needs to gain acceleration by generating password candidates directly on the device(s).

But in order to do that, we have to tell the devices which candidates to generate, which means we have to keep track of some of the candidates on the host. This means we end up with two loops: a loop that runs on the host (the "base loop"), and a loop that runs on the device (the "mod(ifier) loop.") If you are at all familiar with the original oclHashcat, then the concept of "left" and "right" should sound extremely familiar. In the original oclHashcat you had to specify these loops manually, but that changed like 7 years ago (holy shit has it really been that long??)

When we're distributing work between multiple compute nodes, we need a way to control the base loop. This is where --keyspace, -s, and -l come into play. --keyspace reports the size of the base loop that executes on the host so that we know how to divide up the work, and we use -s and -l to control the start/stop positions of the base loop.

With a straight attack with rules (-a 0 -r), Hashcat has an on-device rule engine, meaning the rules are executed directly on the GPU. This means that the base loop is simply the words in the wordlist, and our mod loop is our rules file. This is why when you use --keyspace with a straight attack with rules, it reports the keyspace as the number of usable words in the wordlist.

The calculation of 'hashcat legacy' seems to make more sense for -a 0 as the "number of words in wordlist multiplied by number of rules in rule file." Maybe atom could clarify why this changed?

It didn't change. hashcat-legacy was CPU-only, and thus its architecture wasn't structured for GPU cracking. Candidates were generated and hashed directly in one loop. This architecture does not work for GPU cracking, however. JTR is a prime example of this.

[sjohnny1972]

Thanks for the clarification!

[royce]

I can't really explain it any better than I already did in the thread you linked to. I guess I can try to expand upon it.

Great writeup. Totally stealing this for the FAQ.

https://hashcat.net/wiki/doku.php?id=fre...a_keyspace