12-08-2018, 03:46 AM
Fast hashes can be too fast for brain to track exhausted attacks on a candidate-by-candidate basis (brain featureset 1 or 3), even if there is a very fast network between the brain server and the brain client.
This should make intuitive sense, if you think about it. When cracking without brain, hashcat can guess billions of passwords per second without having to actually *remember* each one of them. If you're cracking a fast hash with brain features -1 or -3, you're telling the brain to *track* trillions of hashes, which is an entirely different workload.
For fast hashes, use brain features -2. This records that an entire *mask* or an entire *dictionary* was exhausted, which is a much simpler workload.
Using -1 or -3 only makes sense if you're attacking a slower hash (like bcrypt). Tracking thousands of candidates per second is then feasible for the brain.
This should make intuitive sense, if you think about it. When cracking without brain, hashcat can guess billions of passwords per second without having to actually *remember* each one of them. If you're cracking a fast hash with brain features -1 or -3, you're telling the brain to *track* trillions of hashes, which is an entirely different workload.
For fast hashes, use brain features -2. This records that an entire *mask* or an entire *dictionary* was exhausted, which is a much simpler workload.
Using -1 or -3 only makes sense if you're attacking a slower hash (like bcrypt). Tracking thousands of candidates per second is then feasible for the brain.
~