Posts: 5,232
Threads: 233
Joined: Apr 2010
02-10-2017, 07:39 PM
(This post was last modified: 02-10-2017, 08:16 PM by atom.)
I can increase rule-based attack speed but for the price of a decreased brute-force attack speed.
I can not guarantee the numbers, but after the change all modes will have the same speed.
The speed will be slower to what combinator-mode is doing right now and depend on the hash-mode.
For NTLM, only half the speed of combinator attack
For SHA256, almost the same speed of combinator attack
Note: This is for fast hashes (NTLM, MD5, VB, etc) only. Slow hashes speeds don't change.
Posts: 441
Threads: 2
Joined: Dec 2015
I'm in favor of the trade off.
Posts: 1
Threads: 0
Joined: Feb 2017
Posts: 4
Threads: 1
Joined: Nov 2015
Posts: 30
Threads: 4
Joined: Jan 2011
Yeah! New algo!
No, wait. Wrong thread.
Yes, do it atom :-)
Posts: 5,232
Threads: 233
Joined: Apr 2010
For those haven't seen it: There's a voting system on top of this thread
Posts: 187
Threads: 40
Joined: Sep 2010
02-10-2017, 09:21 PM
(This post was last modified: 02-10-2017, 09:22 PM by blandyuk.)
I'm in favour but, its a shame brute-force it taking a hit. I presume the classes / interfaces are linked in hashcat which is why this is causing this to happen?
Back in the old days, hashcat was split into 2 apps. Because of this, this issue would never occur.
Surely hashcat can accommodate this without a sacrifice? Is it not the crackers way for speed!
I do realise it would be a lot of work but worth it and we would have the best of both worlds.
Posts: 20
Threads: 6
Joined: Dec 2016
02-11-2017, 01:09 AM
(This post was last modified: 02-11-2017, 01:12 AM by xsdafsr.)
Why brute-force attack speed will decrease after changes?
Posts: 2,935
Threads: 12
Joined: May 2012
Brute force is for noobs.
Posts: 5,232
Threads: 233
Joined: Apr 2010
OK, poll is closed now. Bad thing is that I've found in the meanwhile that the idea didn't work out, so everything will stay as-is
