hashcat / princeprocessor

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

Possible optimization(s) #29

Closed magnumripper closed 8 years ago

magnumripper commented 9 years ago

These three cases are ideally the exact same work load:

$ cat test1
a
b
c

$ time ./pp < test1 --keyspace --elem-cnt-max=3 --pw-max=3
39

real    0m0.085s
user    0m0.009s
sys 0m0.064s

OK...

$ cat test8
aaaaaaaa
bbbbbbbb
cccccccc

$ time ./pp < test8 --keyspace --pw-max=24
39

real    0m1.371s
user    0m1.302s
sys 0m0.061s

This is a lot slower.

$ cat test10
aaaaaaaaaa
bbbbbbbbbb
cccccccccc

$ time ./pp < test10 --keyspace --pw-max=30
39

real    1m37.909s
user    1m37.749s
sys 0m0.136s

This is getting painful. The only difference is the size of each element: They are the same amount and the keyspace is the same. Why is it taking longer to initialize the chains? Are we "processing" a huge number of chains with no elements, or something like that?

magnumripper commented 9 years ago

Hmm is this about length distribution figures?

jsteube commented 9 years ago

Just read this when I already commented for the reason behind here: https://github.com/jsteube/princeprocessor/pull/27#issuecomment-70791589

I think that's the reason

jsteube commented 9 years ago

I don't think we can do anything against this, at least I have no idea atm. The question for me is, do you want to let this issue to be left open as a kind of reminder that this may be some point of future optimization in case we get an idea on how to do it?

magnumripper commented 9 years ago

I have a vague idea about how to attack it. Let's keep it open for a while.

magnumripper commented 8 years ago

A year passed and I can't even remember what idea I had... closing.