hashcat / princeprocessor

Standalone password candidate generator using the PRINCE algorithm
Other
425 stars 98 forks source link

Bump the max. output length limit. #27

Closed magnumripper closed 9 years ago

magnumripper commented 9 years ago

Now that we are untied from static buffers, we can bump the max. output length. This requires a short wordlist though, or keyspace will quickly become astonomical.

$ cat dict
correct
horse
battery
staple

$ ./pp64-len.app < dict --pw-max=25 --keyspace
237

$ ./pp64-len.app < dict --pw-max=25 | grep -nm1 correcthorsebatterystaple
208:correcthorsebatterystaple

The default out length is still 16. I picked 125 as the largest allowed just because it's the maximum throughout JtR's core code, you can change it at will (actually the buffer at line 823 is the only place we need to account for any particular max, unless we change that to be a malloc/free).

EDIT: The above is a bad example since it's allowed with the current IN_LEN_MAX of 32... but you get the idea.

magnumripper commented 9 years ago

(nevermind the bug previously mentioned - there was never any)

magnumripper commented 9 years ago

Hmm maybe we need to give some TLC to wordlen_dist for this to be safe?

magnumripper commented 9 years ago

There seem to be various (but trivial) issues with this commit needing to be addressed before merging. I'm out of time right now.

magnumripper commented 9 years ago

Fixed all issues I could find but there's still some problem.

$ cat test16 
aaaaaaaaaaaaaaaa
bbbbbbbbbbbbbbbb
cccccccccccccccc

$ time ./pp < test16 --keyspace --pw-max=48 
3

real    3m27.753s
user    3m27.542s
sys 0m0.178s

The keyspace should have been 39. It's also very very slow but that's issue #29

magnumripper commented 9 years ago

I'm not sure I understand the wordlen_dist stuff - maybe the last issue is just about that thing so this is actually ready to merge? I squashed it to a single commit now.

jsteube commented 9 years ago

The reason it takes so long is that the total number of chains for a specific output length is:

const int chains_cnt = 1 << (pw_len - 1)

For length 48, it is 140,737,488,355,328 and it iterates through all of them to find out which of them only consist of an element count that is between --elem-cnt-min and --elem-cnt-max. It then skips those that are not within that range but I guess it's just the iteration itself that takes the time.