Strange possible bug with IPB -m 2811

[blandyuk]

First, in this mode, it seems to ignore the increment option. I have the below which clearly states to start from len 6 but it starts from len 1:

oclHashcat-plus64.exe -m 2811 -a 3 -n 320 --gpu-temp-disable --remove -o found2811.txt -i --increment-min=6 hashes2811.txt ?d?d?d?d?d?d?d?d?d?d

Also, when it did get to len 6, it was running @ 326.6M c/s so I would assume when it got to len 7, it would be a bit faster but it's totally stalled at 36719.2k c/s. Been running 15 / 40 mins and no change.

I'm cracking a few 1000 IPB hashes so use the below hashes in here to try and replicate:

http://forum.insidepro.com/viewtopic.php?t=16717

Cheers atom

[blandyuk]

Another update on this, when I use rules, it's runs at 1736.6k c/s

[blandyuk]

Ah I got it, removing -n 320 fixed the issue. Not sure what was going on there.

[M@LIK]

Confirming the ignoring of --increment-min when using -i.
We have to create masks like before:

Code:

?1
?1?1
?1?1?1
?1?1?1?1

[atom]

I doubt its a bug. Its possible that its just to fast, so you dont see first ?1 x 4.

[blandyuk]

No, when I set -i --increment-min=6 with mask ?d?d?d?d?d?d?d?d?d?d, it starts a ?d as u can see it in the statuses.

Also, why is len 6 ?d faster than len 7 ?d

???

[atom]

Because of how BF works, splits are required. They are done automatically by oclHashcat-plus (original oclHashcat did not if you remember left-right thing) and if you choose a small charset these calculations can be wrong so thats why its possible that len 6 ?d is faster than len 7 ?d.

[blandyuk]

Coming back to this one, been trying Combinator attacks using fingerprinting. Used the expander to generate all possibilities, about 1450000 and then tried to do a Combinator attack on the 7000 IPB hashes, speed was about 3000k c/s, normally just over 3100M c/s.

Tested this attack on normal MD5 hashes and it worked ok.

I think there is a definite speed issue with IPB mode. Tested with 10, 500, 2000 and 7000 hashes and salts, all the same.