2

I've written my own John the Ripper module and it's at least working. Sadly I'm not that much into John the Ripper to do any performance analysis, so I just started it with a more or less uncrackable password to see some numbers.

THe hash is salted.

But now the status is kinda strange to me. It starts with:

0g 0:00:00:02 0g/s 140413p/s 140413c/s 140413C/s

But then gets slower with time. After an hour it's at:

0g 0:00:52:12  3/3 0g/s 1383p/s 154053c/s 154053C/s

And after another hour it's at:

0g 0:02:13:13  3/3 0g/s 849.0p/s 154635c/s 154635C/s

After 4 hours I stopped the session with a speed of

0g 0:04:30:43  3/3 0g/s 673.7p/s 154666c/s 154666C/s

Can anyone tell me what could cause that loss in performance? And why are only the candidates/second getting slower while crypts/second and the combination of candidate password and target hash per second is still as fast as before?

Now I encountered another problem to add to the performance loss. Say I have 24 hashes with 24 different salts. One of them has the password test123. If this hash is under the last 5 everything works perfectly. But if it's in the first 5 it won't get cracked (At least not in the second phase of the default john call). I really have no idea what could cause this bug. If my file is smaller (5 hashes) it doesn't encounter this bug and can crack the hash no matter where it is. (According to some tests I made it seems like this could be caused by the different length of the hashes... Still not sure I'm still testing)

Edit:

I've tested some things and since noone answered yet, I'll just modify the question:

The performance loss I experienced above is only if I take big files (310 hashes for the above example)

Now if I take a smaller file ( 6 hashes) the performance is more steady or even seems to increase. Some numbers:

1g 0:00:00:06  3/3 0.1430g/s 33762p/s 136944c/s 136944C/s sheble

and after an hour:

3g 0:00:56:56  3/3 0.000877g/s 41042p/s 156740c/s 156740C/s luecdt

The structure of the files is always the same. The length of the hashes was the same as well this time after I've found the bug mentioned above. But I still have the performance loss with big files.

I've already checked with Valgrind if there is any memory-loss or sth, but nothing came up. RAM usage stays constant over 17 hours as well.

  • 1
    It could be useful to provide the exact command used. The number of hashes computed remains constant, so John the Ripper does not work slower, however this same amount of hashes matches a lower number of candidate passwords, this is usually a consequence of salts (on password => several different hashes depending on the salt). – WhiteWinterWolf Sep 21 '15 at 16:18
  • I just used ./john <myfile> to test it. – Thanathan Sep 22 '15 at 9:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.