Posts: 15
Threads: 2
Joined: Feb 2019
02-11-2019, 03:47 PM
(This post was last modified: 02-11-2019, 07:34 PM by ApexCracker.)
Alright, I'm trying out the brain with an MD5 list to see how much the speed falloff is, but the results were a bit more shocking than expected.
From 67GH/s to around 6MH/s is a reduction of more than 11,000x.
I know it's not optimal for MD5, but I think it'd be nice to not have such a huge reduction in speed.
I've tried this on both 1 and 2 systems (1 client, 1 brain).
Both systems have a mediocre CPU and 64(or more)GB of RAM.
System 1 (Client) Has maxed out CPU usage per GPU and barely any RAM Usage
System 2 (Server) Has almost no CPU usage and almost no RAM Usage
1GBit link between them
I was wondering where the bottleneck in this ordeal is and how the results can be improved.
Posts: 2,301
Threads: 11
Joined: Jul 2010
Have you checked how saturated your network is?
Posts: 15
Threads: 2
Joined: Feb 2019
02-11-2019, 04:09 PM
(This post was last modified: 02-11-2019, 04:12 PM by ApexCracker.)
(02-11-2019, 03:56 PM)undeath Wrote: Have you checked how saturated your network is?
Running brain on the same server, (10Gbit interface) results in about 2MH/s increase (which is most likely the CPU working harder).
The network is unlikely to be saturated as it's a HOME LAN network with almost no traffic.
https://gyazo.com/b829aaeb26a46bd5c2fcb2becb4df9b3
Even after a good amount of minutes, network usage is about RX: 10kB, TX: 20kB so that's unlikely to have any effect
Posts: 15
Threads: 2
Joined: Feb 2019
02-11-2019, 04:14 PM
(This post was last modified: 02-11-2019, 04:16 PM by ApexCracker.)
Running the same -a3 attack on a system with a good CPU (i7-8700K) increases the speed to 4MH/s (for 1 card vs 6MH/s for 4 cards and yes, same card).
Wordlist/rule attack reduces the speed even further from 6-8MH/s for 4 cards to 3MH/s
Posts: 15
Threads: 2
Joined: Feb 2019
02-11-2019, 04:24 PM
(This post was last modified: 02-11-2019, 04:35 PM by ApexCracker.)
Going to make it even more dramatic.
Single hash optimized kernel attack goes from 35GH/s per card to 1.5MH/s per card with brain which is > 23000x decrease
Again, I understand this is good for slower hashes, but I'm trying to see if there is any way to optimize it on my end to see if it can be faster.
If it's not possible, that's the end of my question.
Just a thought that if there's no 'bottleneck' on my end then maybe hashcat should try to hog some more resources
Posts: 5,185
Threads: 230
Joined: Apr 2010
A good rule of thumb is that if you have more than 500kH/s of total performance (all OpenCL devices), hashcat brain (even running on a very fast system) will create a bottleneck. Another rule to add is that if you have more than 1 billion words tests, brain will also create a bottleneck. Please read the release notes very carefully to understand when to use it.
The only way to workaround this is by trying to crack multiple salts at the same time, but if you have only one hash to crack it will not work.
Posts: 15
Threads: 2
Joined: Feb 2019
(02-13-2019, 05:17 PM)atom Wrote: A good rule of thumb is that if you have more than 500kH/s of total performance (all OpenCL devices), hashcat brain (even running on a very fast system) will create a bottleneck. Another rule to add is that if you have more than 1 billion words tests, brain will also create a bottleneck. Please read the release notes very carefully to understand when to use it.
The only way to workaround this is by trying to crack multiple salts at the same time, but if you have only one hash to crack it will not work.
So 500kH/s per salt in a list, correct?
More salts will mean more resources are allocated (assuming salts are known)
Posts: 5,185
Threads: 230
Joined: Apr 2010
Yes, per salt. But salts are always known, otherwise the original authentication system can not do its work either.
