Statprocessor 0.05 bug or something that I don't get

[mastercracker]

Hi Atom. I was testing the statprocessor to see if it would help with cracking more efficiently highly iterated hashes. The approach was the following: I got 1 phpbb3 hash for each length from 1 to 8. I piped it in Oclhashcat-plus 0.08 with the following command line.

Code:

sp64.exe --pw-min 1 --pw-max 8 -t 15 rockyou.hcstat | cudahashcat-plus64.exe -d 1 -n 1 -m 400 -o found.txt test.hash

I wanted to understand better the effect of the t value so this is the only thing was changed between tests. For each test, there is the t value used, the time, how many were cracked, what were the passwords cracked and the rejected value (which might be part of the problem I see):

Code:

After 5 minutes at t 50

2/8

123
wife

rejected:14041088


---------------------------
After 5 minutes at t 22

2/8

123
tiago

rejected: 13664256
---------------------------
AFter 5 minutes at t 15

1/8

tiago

rejected: 6135808
---------------------------
After 10 minutes at t 10

0/8

rejected: 0

------------------------------
After 5 minutes at t 0

3/8

99
123
wife

rejected: 20992000

Normally I would expect that the more I lower the t value, the more I would crack in the keyspace covered in the time allowed. You can see that there is a problem from the very start because going from t 50 to t 22, you loose the coverage of the password wife. From t 22 to t 15, you also loose the password 123. After 10 minutes at t 10, I don't get anything cracked. Another thing that I noticed is that you don't get any password rejection before you crack a hash. As soon as you get 1 the rejected counter flies up. Is this a bug or something that I don't understand?

[atom]

Its the opposite. The higher the -t value, the bigger the keyspace, the more you crack. Only exception is the value 0, which completly disables the threshold (actually, it sets it to 256).

Also, this algorithm is not a dictionary. Chances are high that it generates "123" but there is no guarantee (well, at least as long as you do not use -t 0).

The rejection thing is clear. Once a salt (not a hash) has been cracked, it will be sorted out. There is no need to add it to the hashing iteration pool since it will not crack any hash. Thats why they are skipped. In this case, its added to the rejection counter. Thats required to keep up showing the correct ETA plus not adding these to the speed counter.

[mastercracker]

Ah ok. I knew there was something that I did not get. Thanks atom.