Brain is much slower than expected

[Peanutbutter1]

Hi all, hope I can get some help.

I am making runs with hashcat brain/client but find that it performs worse than using hashcat by itself. The speeds tend to drop by a factor of 1000x, from MH/s to KH/s. The time.est. status remains roughly the same. However, the "Rejected" status often shows a significant reduction in the candidate space, from 25%-99%.

I have tried on ec2 p2.xlarge and p3.2xlarge instances as well as with different algos- MD5, PHPass, VB. Nothing seems to show improvement when using brain. In all cases, I run server on the same box as client, so there are no network bottlenecks to worry about.



Please let me know what other information would be useful to know! Thanks!

[philsmd]

I would suggest starting with reading this: https://hashcat.net/forum/thread-7903.html (most importantly the section "Major Feature: The hashcat brain").

of course the brain is most efficient and I would say sometimes only needed/meaninful for slow hash types (sometimes even the amount of hashes/salts is important too).
the brain has several features/settings to tune it see hashcat --help (most importantly the Brain Client Features, --brain-client-features).

It could make a lot of sense to avoid double work and to use several connected clients at the same time, also to avoid running the same password candidates/attacks again and again.

You could test with several bcrypt hashes etc and you will see that the brain is very clever and skips already done attacks and password candidates and therefore making the cracking much faster if you use it correctly (and how it was intended).
There are also some other forum posts that address speed problems or misconceptions.

Also make sure to use the latest hashcat version and/or the beta version from https://hashcat.net/beta/

[Peanutbutter1]

I would suggest starting with reading this: https://hashcat.net/forum/thread-7903.html (most importantly the section "Major Feature: The hashcat brain").

of course the brain is most efficient and I would say sometimes only needed/meaninful for slow hash types (sometimes even the amount of hashes/salts is important too).
the brain has several features/settings to tune it see hashcat --help (most importantly the Brain Client Features, --brain-client-features).

It could make a lot of sense to avoid double work and to use several connected clients at the same time, also to avoid running the same password candidates/attacks again and again.

You could test with several bcrypt hashes etc and you will see that the brain is very clever and skips already done attacks and password candidates and therefore making the cracking much faster if you use it correctly (and how it was intended).
There are also some other forum posts that address speed problems or misconceptions.

Also make sure to use the latest hashcat version and/or the beta version from https://hashcat.net/beta/

Trying it on bcrypt hashes, I see that it does not offer any speed increases. On --brain-client-features=1 or 3, I see that the speed actually drops even though about 99 percent of the candidates are rejected. Using --brain-client-features=2, the speed remains the same but there are no candidates rejected, even after running the same attack parameters again on the same left list. Why does it not show rejected candidates for features=2? Thanks

[atom]

The speed doesn't get higher with the brain.

[Peanutbutter1]

The speed doesn't get higher with the brain.

Should I expect the Time. Est. to be lowered?

[philsmd]

I guess that depends on how large the percentage of rejected passwords is and how fast the algorithm is.

brain doesn't make the H/s speed of your GPUs faster, that only depends on the OpenCL devices and tuning options.

but in general if cracking is slower than the network (communication) and the task of rejecting the passwords/tasks, hashcat will finish sooner.

You can try it yourself with a dict where you have 50% completed already and send to brain. The next time that hashcat starts it won't use those password candidates and skip them and continue with the second half (after the first 50% already done). This should be faster if network is not an issue and if the hashing algorithm is slow enough as explained in https://hashcat.net/forum/thread-7903.html (especially the sections "The costs of hashcat brain" and "The brain and the bottlenecks" are interesting for this discussion)