Do not try to write --keyspace yourself

[atom]

Keyspace is not the number of words in a wordlist:

$ wc -l rockyou.txt 
14344391 rockyou.txt
$ ./hashcat --keyspace rockyou.txt 
14344384

So 14344391 != 14344384.

It's also dynamic when it comes to masks:

$ ./hashcat --keyspace -a 3 ?a
1
$ ./hashcat --keyspace -a 3 ?a?a
95
$ ./hashcat --keyspace -a 3 ?a?a?a
9025
$ ./hashcat --keyspace -a 3 ?a?a?a?a
857375
$ ./hashcat --keyspace -a 3 ?a?a?a?a?a
81450625

So you think you see the logic? Now this:

$ ./hashcat --keyspace -a 3 ?a?a?a?a?a?a
81450625
$ ./hashcat --keyspace -a 3 ?a?a?a?a?a?a?a
81450625

It's on a limit? No it's not!

$ ./hashcat --keyspace -a 3 ?a?a?a?a?a?a?a?a
7737809375

And it changes over time:

v3.6.0:

$ ./hashcat --keyspace rockyou.txt 
14343296

v4.0.x:

$ ./hashcat --keyspace rockyou.txt 
14344384

So 14343296 != 14344384.

The morale of this: Don't try to emulate how it works, just use --keyspace

[atom]

There's another nice example! The hash-mode has also influence:

$ ./hashcat --keyspace -a 3 ?d?d?d?d?d?d?d?d -m 0
100000
$ ./hashcat --keyspace -a 3 ?d?d?d?d?d?d?d?d -m 400
10000000

[atom]

Here's more crazy stuff. The mask itself can have an influence even if the length does not change:

$ ./hashcat --keyspace -a 3 ?d?d?d?d?d?d?d?d
100000
$ ./hashcat --keyspace -a 3 ?d?dx?d?d?d?d?d
10000

But not always:

$ ./hashcat --keyspace -a 3 ?d?d?d?d?d?d?d?d
100000
$ ./hashcat --keyspace -a 3 ?a?d?d?d?d?d?d?d
100000

[kiara]

[sjohnny1972]

What is the rationale behind this behavior, just wondering? In the Hashcat help I find: "Show keyspace base:mod values and quit". What is base and mod(ulo)?

When I try with rule expansion the value doesn't increase, I would've guessed otherwise:

Code:

./hashcat64.bin -a 0 -r ../files/best64.rule --keyspace ../files/rockyou.txt

[royce]

For more on the scope and impact of keyspace, see

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

Also, atom: can you speak to what keyspace is actually intended to be used for?

[philsmd]

The output of --keyspace can be used to distribute cracking, i.e. you can use the value from --keyspace and divide it into x chunks (best would be if the chunk size depends on the performance of your individual nodes if they are different) and use the -s/-l parameters for distributed cracking.

[undeath]

"keyspace" in itself seems to be a pretty well-defined word but does not match what hashcat considers "keyspace". Maybe this option should be renamed to something more fitting.

[royce]

*lightbulb*

Ahhhh ... so they only need to be "proportional" within specific attack type/combos, and that's why they can't be compared across them! Because it's *called* a keyspace ... but it isn't really strictly an actual keyspace in the literal sense, just a way to divide up work within that attack.

(Hmm ... so in retrospect, using word other than "keyspace" (which means something specific in the general cracking context to most users) would have probably been better -- maybe "workset" or something like that). [Edit: yeah, what undeath said ]

Now I finally get it. Thanks!

[evilmog]

*lightbulb*

Ahhhh ... so they only need to be "proportional" within specific attack type/combos, and that's why they can't be compared across them! Because it's *called* a keyspace ... but it isn't really strictly an actual keyspace in the literal sense, just a way to divide up work within that attack.

(Hmm ... so in retrospect, using word other than "keyspace" (which means something specific in the general cracking context to most users) would have probably been better -- maybe "workset" or something like that). [Edit: yeah, what undeath said ]

Now I finally get it. Thanks!

Please don't change --keyspace, hashtopussy, hashtopus, hashview all use it for distribution as does my skip and limit calculator.

Do you want me to do a writeup on how the distribution works?