is descrypt slow after ocl v1.31?

[lavisher]

I am having trouble with descrypt cracking performance. It used to be fast (v1.31) but now it is going slow for me (v1.33 or v1.35). Benchmarks reveal the same numbers for each version and so do short runs but once I get a big enough dictionary, everything falls apart. It was suggested to me to try piping (shown below) but that didn't fix the problem.

Detailed below, both releases were freshly un-7zr'd immediately prior to testing. I use the same rules, same dictionary and same test hashes in both tests. The only thing that changes is the cuda version. The same problem occurs with 1.35.

I will be grateful for any help.

Here is the output:

lavisher@crackhost:~/test/cudaHashcat-1.31$ ../hashcat-0.49/hashcat-cli64.bin --stdout dictionary.txt -r ~/audit/2015-02-12.rules | ./cudaHashcat64.bin --hash-type 1500 -o output.txt ~/audit/hashes.crypt

[...snip...]

Session.Name...: cudaHashcat
Status.........: Exhausted
Input.Mode.....: Pipe
Hash.Target....: File (/home/lavisher/audit/hashes.crypt)
Hash.Type......: descrypt, DES(Unix), Traditional DES
Time.Started...: Wed Apr 15 16:30:58 2015 (2 hours, 12 mins)
Speed.GPU.#1...: 118.9 kH/s
Recovered......: 403/1527 (26.39%) Digests, 66/607 (10.87%) Salts
Progress.......: 2979221737493
Skipped........: 48207862800
Rejected.......: 2457490450973
HWMon.GPU.#1...: -1% Util, 56c Temp, 62% Fan

Started: Wed Apr 15 16:30:58 2015
Stopped: Wed Apr 15 18:43:44 2015

lavisher@crackhost:~/test/cudaHashcat-1.31$ cd ../cudaHashcat-1.33/
lavisher@crackhost:~/test/cudaHashcat-1.33$ ../hashcat-0.49/hashcat-cli64.bin --stdout dictionary.txt -r ~/audit/2015-02-12.rules | ./cudaHashcat64.bin --hash-type 1500 -o output.txt ~/audit/hashes.crypt

[...snip...]

Session.Name...: cudaHashcat
Status.........: Running
Input.Mode.....: Pipe
Hash.Target....: File (/home/lavisher/audit/hashes.crypt)
Hash.Type......: descrypt, DES(Unix), Traditional DES
Time.Started...: Wed Apr 15 19:24:34 2015 (14 hours, 1 min)
Speed.GPU.#1...: 67783 H/s
Recovered......: 404/1527 (26.46%) Digests, 66/607 (10.87%) Salts
Progress.......: 2820735306730
Skipped........: 46255920641
Rejected.......: 2320884538284
HWMon.GPU.#1...: -1% Util, 43c Temp, 45% Fan

[snip - SESSION NOT COMPLETE]

[Rolf]

Judging by the temperature of the GPU in the second example, it is underutilized.

[atom]

I'm testing with the following system:

Device #1: GeForce GTX 980, 4095MB, 1215Mhz, 16MCU
Device #2: GeForce GTX 750 Ti, 2047MB, 1110Mhz, 5MCU
Device #3: GeForce GTX 560 Ti, 1023MB, 1660Mhz, 8MCU

From benchmark -b speed is OK:

1.31:

Speed.GPU.#1.: 96327.5 kH/s
Speed.GPU.#2.: 28080.3 kH/s
Speed.GPU.#3.: 18439.4 kH/s

1.36 (beta 30):

Speed.GPU.#1.: 95496.5 kH/s
Speed.GPU.#2.: 28245.5 kH/s
Speed.GPU.#3.: 18851.3 kH/s

And with -a0 (wordlist based attack) speed is OK:

command used:

$ ./mp64.bin ?a?a?a?a?a?a?a | ./cudaHashcat64.bin w8GvlER3.Xkj6 -m 1500 -r rules/generated2.rule -u 1024 -n 16 --potfile-disable --runtime 60 --status --status-timer 2 -d 1

1.31:

Progress.......: 5435817984

1.36 (beta 30):

Progress.......: 5838471168

That means latest version is fastest (more progress in the same time)

[atom]

Btw, my gutfeeling tells me this could be maybe somehow related to password length (and rejection). Try with a wordlist where no word has the length > 8

[lavisher]

Here is what I did for dictionaries:

Code:

$ wc -l english.dict
3160120 english.dict
$ cat english.dict | awk 'length<9' > english-8.dict
$ wc -l english-8.dict                                      
1182707 english-8.dict
$ cat english.dict | awk 'length<11' > english-10.dict
$ wc -l english-10.dict
2211209 english-10.dict
$ cat english.dict | awk 'length>9' > english-10+.dict
$ wc -l english-10+.dict
1264626 english-10+.dict
$

[lavisher]

Then I ran OCL Hashcat and got timing/reject results like this (mms):

Code:

.
                   v1.31         v1.35
dictionary        time/rejects time/rejects
---------------- ----- ----   ----- ----
english-10+.dict  0:01 100%   12:33   0%
english.dict     19:24  40%   30:03   0%
english-10.dict  19:37  14%   22:05   0%
english-8.dict   12:16   0%   12:02   0%

I guess the rejected bit looks interesting.

[epixoip]

Yep, looks like your problem is the high reject rate. Spending more time rejecting than it is cracking.

[atom]

I've changed rejection handling for v1.36 as it was with v1.31. It's clearly superior. You should test with latest beta version

[lavisher]

I tested and found that the problem is completely fixed in 1.36 as you have suggested.

Thanks!