SHA1 speed difference
#1
Hi all,

I have the following issue.

Trying this on GeForce GTX 1080 whit CUDA API (CUDA 11.2). Hashcat is v6.2.3.
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b

I get speed of 8408.5 MH/s. Which looks OK.
Code:
b89eaac7e61417341b710b727768294d0e6a277b:hashcat Session..........: hashcat Status...........: Cracked Hash.Name........: SHA1 Hash.Target......: b89eaac7e61417341b710b727768294d0e6a277b Time.Started.....: Sat Aug 14 19:30:54 2021 (2 secs) Time.Estimated...: Sat Aug 14 19:30:56 2021 (0 secs) Kernel.Feature...: Optimized Kernel Guess.Mask.......: ?1?2?2?2?2?2?2 [7] Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined Guess.Queue......: 7/15 (46.67%) Speed.#1.........:  8408.5 MH/s (77.38ms) @ Accel:64 Loops:512 Thr:1024 Vec:1 Recovered........: 1/1 (100.00%) Digests Progress.........: 12079595520/134960504832 (8.95%) Rejected.........: 0/12079595520 (0.00%) Restore.Point....: 0/1679616 (0.00%) Restore.Sub.#1...: Salt:0 Amplifier:8704-9216 Iteration:0-512 Candidate.Engine.: Device Generator Candidates.#1....: v77eran -> Lurzto8 Hardware.Mon.#1..: Temp: 62c Fan:  0% Util: 99% Core:1759MHz Mem:4513MHz Bus:16

Applying a mask like this
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset ?b?b?b?b?b?b
I still get the same speed
Code:
Speed.#1.........:  8550.0 MH/s (77.38ms) @ Accel:32 Loops:1024 Thr:1024 Vec:1

Prepending up to two fixed bytes to the mask the speed remains
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset 0102?b?b?b?b?b?b Speed.#1.........:  8635.6 MH/s (76.57ms) @ Accel:32 Loops:1024 Thr:1024 Vec:1


Prepending 3 fixed bytes to the mask the spped drops to 5000 MH7s,. Which is also fine.
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset 010203?b?b?b?b?b?b Speed.#1.........:  5028.6 MH/s (37.89ms) @ Accel:64 Loops:256 Thr:1024 Vec:1


Now the problem. Prepending 4 or more fixed bytes the speed drops to 50 MH/s.
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset 01020304?b?b?b?b?b?b Speed.#1.........: 45324.1 kH/s (0.66ms) @ Accel:64 Loops:1 Thr:1024 Vec:1


Funny. If the fixed bytes are in the middle or at the end like this. The speed ramps up again to 5 to 8 GH/s
Code:
hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset ?b01020304?b?b?b?b?b Speed.#1.........:  5067.4 MH/s (37.64ms) @ Accel:64 Loops:256 Thr:1024 Vec:1 hashcat.exe -m 100 -w 3 -O -a 3 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset ?b?b?b?b?b?b01020304 Speed.#1.........:  8569.8 MH/s (77.08ms) @ Accel:32 Loops:1024 Thr:1024 Vec:1

The question. What am I doing wrong?
Thanks for your help.

Regards
rste
Reply
#2
Nothing, that's exactly the expected behavior. The first 4 byte are used as amplifiers. If you really need to brute force the first 4 byte you can use hybrid rules in -a 0 mode for almost full speed.
Reply
#3
(08-14-2021, 07:10 PM)atom Wrote: Nothing, that's exactly the expected behavior. The first 4 byte are used as amplifiers. If you really need to brute force the first 4 byte you can use hybrid rules in -a 0 mode for almost full speed.

Thank you. 
I couldn't make it with rules in -a 0, because I found no way to append in byte mode when used with --hex-charset.

What worked was generating a dictionary 
Code:
$PSDefaultParameterValues['Out-File:Encoding'] = 'utf8' 0..255 | % {   $L1 = [System.Convert]::ToString($_,16).PadLeft(2,'0')   0..255 | % {     $L2 = [System.Convert]::ToString($_,16).PadLeft(2,'0')     echo ('000102030405060708090A0B0C0D0E0F'+$L1+$L2) >> prependmask.txt  } }

and using -a 6
Code:
.\hashcat.exe -m 100 -w 3 -O -a 6 b89eaac7e61417341b710b727768294d0e6a277b --hex-charset  prependmask.txt  ?b?b?b

The only problem is in -a 6 mode I get "Integer overflow detected in keyspace of mask" with only 4 ?b regardless of the dictionary size. In -a 3 mode overflow happens with 8 ?b. So to test for 6 bytes I have to add another loop to the dictionary generation.
Reply