Closed magnumripper closed 9 years ago
(nevermind the bug previously mentioned - there was never any)
Hmm maybe we need to give some TLC to wordlen_dist for this to be safe?
There seem to be various (but trivial) issues with this commit needing to be addressed before merging. I'm out of time right now.
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
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.
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.
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.
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.