iterations and loops confusion
#1
I promise to the whole forum, that is my last topic for closest time, cuz I've created already 3 , but all of them for different subjects
nvm

What about Loop confusion

On bcrypt benchmark I could see this data:

Hashmode: 3200 - bcrypt $2*$, Blowfish (Unix) (Iterations: 32) Speed.#1.........:    54069 H/s (19.72ms) @
 Accel:1 Loops:32 Thr:24 Vec:1
It says 32 iterations, 32 loops

And when running real bruteforce I have little bit different data :
Accel:2 Loops:256 Thr:24 Vec:1
Accel and Thr difference not so important for me, as the amount of Loops : 256

Could you tell me please, do I understand correctly, that is because of different parameter of Rounds used while encrypting the string ? 
e.g. $2$10  and $2$5 
And if I run bruteforce on  "lower amount of rounds-hash", it will change?

Or maybe I am running something wrong, if so, could you help me please
Reply
#2
Yeah it is simple like that, but you have to take a look at iteration count, the rest is done by hashcat autotune for your graphicscard

the "cost" factor bcrypt means 2^costs=rounds, so 2^5 is 32 and 2^10 is 1024, the rest like mentioned is managed by autotune, maybe your graphicscard is not capable of doing 1024 loops in a row or something similar so autotune splits it to 4*256.

cost/rounds or iterations where intruduced to slow down cracking, imagine this, (i use lower numbers just for showing purposes) you are able to compute 1000 hashes per second for a single round, introduce an iteration of 10, you will end up with just 100 hashes per second and so on
Reply
#3
(08-07-2023, 12:14 PM)Snoopy Wrote: Yeah it is simple like that, but you have to take a look at iteration count, the rest is done by hashcat autotune for your graphicscard

the "cost" factor bcrypt means 2^costs=rounds, so 2^5 is 32 and 2^10 is  1024, the rest like mentioned is managed by autotune, maybe your graphicscard is not capable of doing 1024 loops in a row or something similar so autotune splits it to 4*256.

cost/rounds or iterations where intruduced to slow down cracking, imagine this, (i use lower numbers just for showing purposes) you are able to compute 1000 hashes per second for a single round, introduce an iteration of 10, you will end up with just 100 hashes per second and so on

seems like really it is doing 4x256, beacuase of I am using $2$10 hash for test, which is 2^10, 1024 Iterations. I will try another types of bcrypt hashes, with less or more iterations, and message here. Thank you for you support, really appreciate that! Thanks
Reply
#4
```
Accel:1 Loops:32 Thr:24 Vec:1
```
These are tuning values and may not directly correlate with anything regarding the algorithm you are attacking. The Accel is an "outer loop" part of the kernel, Loops is the "inner loop" part of the kernel, Threads is the parallel threads being executed, and Vec is the backend Vector Width. These may not be understandable if you aren't familiar with the inner workings of our kernels, but that's fine and there's no reason to worry about them.
Reply
#5
(08-07-2023, 06:09 PM)Chick3nman Wrote: ```
Accel:1 Loops:32 Thr:24 Vec:1
```
These are tuning values and may not directly correlate with anything regarding the algorithm you are attacking.... These may not be understandable if you aren't familiar with the inner workings of our kernels, but that's fine and there's no reason to worry about them.

Is there a cheatsheet to something like "This should be the highest #", or a standard what ever gets me the highest H/s?
I'm attempting to tune my 4090 on -a 3 -m 11300 ... -w 4 using GWE and am getting the following:
GPU Offset 155     Mem Offset 501
233.3 kH/s (292.91ms) @ Accel:16 Loops:1024 Thr:1024 Vec:1
---
GPU Offset 186     Mem Offset 601
225.8 kH/s (303.09ms) @ Accel:32 Loops:512 Thr:1024 Vec:1

Thanks for your time
Reply