Slow Left Mask or Dict

[NeonFlash]

If the left mask results in a less number of combinations like:

?d
?l
?u
?d?l

the attack is generally slower (in hybrid attack mode)

Similarly, if the number of words in the left dictionary in a combined dictionary attack are less, the speed of the attack is slow.

Is there a way to speed this up? With a light left mask/wordlist, can we have a better speed?

In some cases I have observed, the speed slowly increasing with time when the left mask/wordlist is small and right mask/wordlist is large.

As per my understanding, oclhashcat-plus loads the right wordlist first followed by the left one. I am not sure of the limitations but it would definitely be a significant improvement if this could be optimized.

[M@LIK]

Yup, I noticed this too.
I just leave it for 5-10mins to reach the maximum speed.

[fizikalac]

I think this is a GPU optimization issue. Some operations are just faster on CPU. Please correct me if I'm wrong (atom). I don't really think that there is a way of speeding this up and it doesn't make much sense anyway.

[NeonFlash]

@M@LIK: Thank you for confirming. Yes, I also leave it for a while to let it attain the maximum speed.

@fizikalac: It could be a GPU optimization issue and there is indeed a scope for improvement. Yes, it does make sense to speed up this attack vector.

[atom]

oclHashcat-plus can not automatically do this for you. You have to generate enough work on the left side. What you can do is that you add some placeholder. for example if "-a 7 ?d?d wordlist" is to slow for you, you can do "-a 7 -1 ?l?d?s?u ?d?d?1?1 wordlist". Ofc, this is not exactly the same, but then you can use the cutb utility from hashcat-utils to remove the first 2 chars from each word in your dictionary (and dont forget to sort -u afters, otherwise it would not make much sense)... Thats all I can do.

[fizikalac]

oclHashcat-plus can not automatically do this for you. You have to generate enough work on the left side. What you can do is that you add some placeholder. for example if "-a 7 ?d?d wordlist" is to slow for you, you can do "-a 7 -1 ?l?d?s?u ?d?d?1?1 wordlist". Ofc, this is not exactly the same, but then you can use the cutb utility from hashcat-utils to remove the first 2 chars from each word in your dictionary (and dont forget to sort -u afters, otherwise it would not make much sense)... Thats all I can do.

Atom, can you please provide us with more technical info? Why does the GPU need enough work on both sides to be fast? I'm really interested in this. Thank you.

[atom]

if you take the hd5970 for example you have 3200 mini processors waiting for work. if you create only work for 100 of them you can not expect full speed.

[NeonFlash]

Thanks atom. What are the possible scenarios where there will be a speed lag?

For instance, I am running the following attack:

Combination Attack with the left dict (size 35 Mb) and right dict (size 830 Mb). Now, even though the size of right dict is way too big as compared to left dict, but the size of left dict isn't too small either.

So, I want to know which scenarios do we say there is "not enough work for the left mask"?

Is it when sizeof(right dict or mask) is way too big as compared to sizeof(left dict or mask)

or is it when both sizeof(right dict or mask) and sizeof(left dict or mask) is too small

or is it when sizeof(right dict or mask) is sufficiently large but the sizeof(left dict or mask) is too small, which is the case we discussed above.

Isn't it possible for the idle mini processors to get a workload if they are free? If the workload distribution is even among multiple GPU cores, then why would we have idle cores?

Please correct me if I am wrong, I am interested to learn more about the GPU architecture as well

---

A quick update. I just tried to split the big right dictionary into smaller dictionaries using the splitlen utility from the hashcat-utils suite and it improves the performance.

I am still testing it as the size of the split dictionaries are variable.

My guess is that when the size of the left and right dictionaries are comparable and also considerably large, we get the best performance from the GPU.

However, understanding from the GPU architecture perspective would be interesting indeed.