Posts: 3
Threads: 1
Joined: Apr 2016
04-06-2016, 11:39 PM
(This post was last modified: 04-06-2016, 11:42 PM by apleshak.)
Greetings,
I've read several posts detailing the CPU bottleneck that occurs during combinator attacks (CPU can't generate combinations fast enough for the GPU). Although I am aware of mask/rule workarounds for this issue, I'm wondering whether anyone has successfully employed multiple CPUs, seated on the same motherboard, (or a CPU cluster) to widen this choke point substantially at a reasonable price?
Posts: 2,940
Threads: 12
Joined: May 2012
Hmm doesn't quite sound like you have a grasp on the issue. Are you talking about when piping combinator.bin from hashcat-utils into oclHashcat via stdin? If so, the issue isn't that it can't generate candidates fast enough on the CPU (or at least that's not the biggest issue.) The issues are 1. you have no amplifier (this is where GPU acceleration comes from with fast hashes) and 2. host-device transfer latency. You could have a dozen CPUs generating candidates, you still won't get any GPU acceleration that way.
But we have a native combinator attack mode in oclHashcat so piping combinator.bin into oclHashcat is a bit stupid anyway. What precisely are you trying to accomplish?
Posts: 3
Threads: 1
Joined: Apr 2016
04-07-2016, 01:12 AM
(This post was last modified: 04-07-2016, 01:14 AM by apleshak.)
(04-06-2016, 11:50 PM)epixoip Wrote: Hmm doesn't quite sound like you have a grasp on the issue. Are you talking about when piping combinator.bin from hashcat-utils into oclHashcat via stdin? If so, the issue isn't that it can't generate candidates fast enough on the CPU (or at least that's not the biggest issue.) The issues are 1. you have no amplifier (this is where GPU acceleration comes from with fast hashes) and 2. host-device transfer latency. You could have a dozen CPUs generating candidates, you still won't get any GPU acceleration that way.
But we have a native combinator attack mode in oclHashcat so piping combinator.bin into oclHashcat is a bit stupid anyway. What precisely are you trying to accomplish?
Thanks for the speedy reply, epixoip! My bad, I've misinterpreted this hashcat
article. In general I'm trying to ascertain the extent of the benefits of multiple CPUs for various attack methods when there are plentiful GPU resources available. More specifically in brute-force and combinator attacks, as well as the mask to rule conversion step described in that article.
Posts: 2,940
Threads: 12
Joined: May 2012
Candidates are not generated on the CPU, they are generated on the GPU. The only time this is not true is if using an external generator and piping into oclHashcat, in which case you need to add amplifier. Otherwise all of the candidates will be provided through the base loop and there will be no mod loop to generate candidates on the device, so you will not get any acceleration.
Posts: 3
Threads: 1
Joined: Apr 2016
(04-07-2016, 01:39 AM)epixoip Wrote: Candidates are not generated on the CPU, they are generated on the GPU. The only time this is not true is if using an external generator and piping into oclHashcat, in which case you need to add amplifier. Otherwise all of the candidates will be provided through the base loop and there will be no mod loop to generate candidates on the device, so you will not get any acceleration.
Solves my riddle, thanks! Your post
here was helpful. Looks like I need to do more research. Is there a better place than the github repo to start learning hashcat's pipeline for various algorithms?
