3

I'm doing a test with John The Ripper, to see how long it takes to crack a zip password.

One test is one an old intel NUC, which has an i5 processor and 4 cores. These are the numbers I'm getting:

0g 3:23:53:55  3/3 0g/s 11260Kp/s 11260Kc/s 11260KC/s idanloob6y..idanlokntz
0g 3:23:54:55  3/3 0g/s 11260Kp/s 11260Kc/s 11260KC/s i twskl2b1..i twskbfrk
0g 3:23:57:16  3/3 0g/s 11260Kp/s 11260Kc/s 11260KC/s dutyen1d48..dutyenib04
0g 4:00:02:19  3/3 0g/s 11260Kp/s 11260Kc/s 11260KC/s 1724b3by#9..1724b33t02
0g 4:00:04:07  3/3 0g/s 11260Kp/s 11260Kc/s 11260KC/s 1blpyryiz7..1blpyrcm71

All 4 cores are at 99% according to htop.

Now I'm processing the same file on a c4.4xlarge on EC2, which should be suitable for heavy cpu usage. I start John The Ripper, and according to htop, all 16 cores are number-crunching as well.

A big surprise occurred when I look at the numbers:

Loaded 1 password hash (PKZIP [32/64])
Will run 16 OpenMP threads
Proceeding with incremental:ASCII
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 3:22:50:03  3/3 0g/s 11262Kp/s 11262Kc/s 11262KC/s aiyuckla161..aiyuckjk346 
0g 3:22:50:14  3/3 0g/s 11262Kp/s 11262Kc/s 11262KC/s byaleetoren..byaleeb1059 
0g 3:22:51:07  3/3 0g/s 11265Kp/s 11265Kc/s 11265KC/s lmclitola25..lmclitils94 
0g 3:22:52:53  3/3 0g/s 11271Kp/s 11271Kc/s 11271KC/s tkinemonggy..tkinemcamm2

Those are not better than on my cheap Intel NUC.

Am I missing something here, or is the performance identical on both machines, despite the fact my EC2 instance has 16 cores compared to 4 cores on the NUC?

One more thing: I transfered the john.rec from the intel NUC to the EC2 instance, so it would continue where the NUC stop. Can that has something to do with it?

1
  • I removed the .rec file from the EC2 instance, and now I'm getting better numbers. Can someone with more knowledge of John The Ripper confirm that this is expected behaviour? Does the .rec file contains machine information when it is initially created? Nov 29, 2016 at 11:57

1 Answer 1

2

Your assumption is correct.

John The Ripper by default will save its state every 10 minutes. When you ran it on your NUC the numbers first displayed to you were saved in the .rec file from one of those auto saved states. When you uploaded it onto the instance the state saved in the .rec file still showed the same numbers as your NUC because it was not updated yet.

When you deleted the .rec file a new one was created with the new numbers. If you want to see the numbers in live while it is running you can type any key into the console.

You can read a little more about it here.

1
  • I'm still surprised that the numbers are quite low. I'm testing on an EC2 c4.8xlarge instance. I get about 35000Kp/s. Which is about 3x times faster than the NUC. However, the EC2 8xlarge has 36 cores, that's 9x more than the NUC. I expected a bigger difference, Dec 5, 2016 at 10:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .