+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Deprecated; Previous versions (https://hashcat.net/forum/forum-29.html)
+--- Forum: Old oclHashcat Support (https://hashcat.net/forum/forum-38.html)
+--- Thread: Possible descrypt performance issue (/thread-4964.html)
Possible descrypt performance issue - me.scotty - 01-06-2016
Was really excited to download the new version and check the performance!
Note: Same video card for all below.
However, installed Catalyst 15.7.1 for oclHashcat 2.0.1
For the previous release I was getting about 35MH/s (single hash)
For 2.01 I got an amazing 152MH/s.
Wow!
So far, so good.
For my second benchmark I ran with 13 descrypt hashes - but all the same salt.
(as we all know, descrypt has a very limited number of salts, so this performance is important).
Unfortunately, performance dropped to 30MH/s.
So, is the simply a math error in reporting of the performance?
Or, is this an artifact of the algorithm changes?
(my fear is that it's the latter...)
RE: Possible descrypt performance issue - atom - 01-12-2016
It depends, sure there's a performance drop related to multihash because we can not know the salt value at compile time but as long as you use -a 3 the performance should be only a little bit slower. Please verify again and if you can reproduce it post an issue on GitHub and include all information devs need to reproduce it locally so we can fix it
RE: Possible descrypt performance issue - me.scotty - 01-13-2016
(01-12-2016, 02:17 PM)atom Wrote: Please verify again and if you can reproduce it post an issue on GitHub and include all information devs need to reproduce it locally so we can fix itMany thanks for your response.
My gut feeling is still leaning toward this being an "inherent in the design" issue.
I don't know how JtR (which also utilizes bitslicing) behaves in cases like this, because I stopped using it when hashcat came along...
But since you seem to think it can be "fixed", I'll post the issue on github.
Note: It's more important than it first appears, because while descrypt officially can have 4096 salts (I've seen some spec extensions here and there), in practice ~60% of the hashes contain only 100 salts (the digits).
(Apparently, the scripts that generate the hashes from passwords supply a random salt that's not entirely random.)
Code:
(Note: single hash masked)
Session.Name...: all
Status.........: Running
Input.Mode.....: Mask (?1?1?1?1?1?1?1?1) [8]
Hash.Target....: xxxxxxxxxxxxx
Hash.Type......: descrypt, DES(Unix), Traditional DES
Time.Started...: Tue Jan 12 15:37:35 2016 (6 secs)
Time.Estimated.: Fri Jan 29 11:19:59 2016 (16 days, 19 hours)
Speed.GPU.#1...: 76175.5 kH/s
Speed.GPU.#2...: 76185.9 kH/s
Speed.GPU.#*...: 152.4 MH/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 1019215872/218340105584896 (0.00%)
Rejected.......: 0/1019215872 (0.00%)
Restore.Point..: 0/916132832 (0.00%)
HWMon.GPU.#1...: 98% Util, 51c Temp, 90% Fan
HWMon.GPU.#2...: 98% Util, 50c Temp, 30% Fan
Session.Name...: all
Status.........: Running
Input.Mode.....: Mask (?1?1?1?1?1?1?1?1) [8]
Hash.Target....: File (C:\descrypt(x13).txt)
Hash.Type......: descrypt, DES(Unix), Traditional DES
Time.Started...: Tue Jan 12 15:35:29 2016 (8 secs)
Time.Estimated.: Wed Apr 06 15:14:53 2016 (84 days, 22 hours)
Speed.GPU.#1...: 15133.2 kH/s
Speed.GPU.#2...: 15144.5 kH/s
Speed.GPU.#*...: 30277.7 kH/s
Recovered......: 0/13 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 251658240/218340105584896 (0.00%)
Rejected.......: 0/251658240 (0.00%)
Restore.Point..: 0/916132832 (0.00%)
HWMon.GPU.#1...: 99% Util, 57c Temp, 82% Fan
HWMon.GPU.#2...: 99% Util, 56c Temp, 30% FanRE: Possible descrypt performance issue - atom - 01-14-2016
Should be fixed with latest beta
RE: Possible descrypt performance issue - me.scotty - 01-19-2016
Looks good.
Thanks to atom for the timely response.
BTW - The performance improvement is very impressive...