0

I temporarily forgot a password for a file I had, and used a software called KRyLack RAR Password Recovery to try and recover my password. Fortunately (and unfortunately after purchasing this software), I remembered my password and was able to to open my file.

My question is about the speed of passwords this software tries per second - totally out of curiosity. I get this is probably subjective to the speed of the machine, but I'm running a i7, and for example at its peak, this software would try 13 passwords per second. Why is this? I tried with a length of 3 caracters, 4, 5, 9, 10 and the same speed was achieved. This seems like an imposed limit for a reason, is this due to some limitation on winrar itself, or is it something else?

  • “Why is this?” - This can be explained by the fact the program was single threaded. GPU is much more efficient at these type of loads. – Ramhound Feb 20 '18 at 23:01
  • 1
    The software you chose is 32-bit, actually it might be 16-bit since it supports 16-bit Operating Systems. Additionally, it definitely, doesn’t support GPU computation. – Ramhound Feb 20 '18 at 23:07
  • @Ramhound So, certainly this is susceptible to everything in an environment that has to be taken into account, and I get that, and perhaps my expectations were way off. And so does this mean that it is not being limited by anything else other than program being made in 32/16 bit software? In other words, this would not be a limit explicitly imposed by the software for some reason? – riseagainst Feb 23 '18 at 16:15
  • If the application is single threaded that means you could throw a 32 core processor and it would perform identically to a single core of running at the same frequency (more or less outside of architectural changes). If the application is actually 16-bit then that also would be a factor in the performance due to the way the hash algorithm works. Royce's answer explains the reason why using a CPU, to perform a brute force attack, is the incorrect approach to calculate PBKDF2-HMAC-SHA256 hashes. – Ramhound Feb 23 '18 at 16:59
2

The algorithm used by WinRAR to hash the password that protects the encryption key - PBKDF2-HMAC-SHA256:

6. Changes in RAR 5.0 encryption algorithm:

 a) encryption algorithm is changed from AES-128 to AES-256 in CBC mode.
   Key derivation function is based on PBKDF2 using HMAC-SHA256;

... is designed to be slow, and specifically to be resistant to high-speed offline attacks ... though CPU will indeed be slower:

$ hashcat -w 4 -O -b -D 1 -m 10900
hashcat (v4.1.0) starting in benchmark mode...

* Device #7: AMD FX(tm)-8350 Eight-Core Processor, 8034/32139 MB allocatable, 8MCU

Hashmode: 10900 - PBKDF2-HMAC-SHA256 (Iterations: 999)

Speed.Dev.#7.....:    21213 H/s (370.38ms)

... than GPU:

$ hashcat -w 4 -O -b -D 2 -m 10900
hashcat (v4.1.0) starting in benchmark mode...

* Device #1: GeForce GTX 1080, 2028/8113 MB allocatable, 20MCU
* Device #2: GeForce GTX 1080, 2028/8114 MB allocatable, 20MCU
* Device #3: GeForce GTX 1080, 2028/8114 MB allocatable, 20MCU
* Device #4: GeForce GTX 1080, 2028/8114 MB allocatable, 20MCU
* Device #5: GeForce GTX 1080, 2028/8114 MB allocatable, 20MCU
* Device #6: GeForce GTX 1080, 2028/8114 MB allocatable, 20MCU

Hashmode: 10900 - PBKDF2-HMAC-SHA256 (Iterations: 999)

Speed.Dev.#1.....:  1222.0 kH/s (478.00ms)
Speed.Dev.#2.....:  1204.6 kH/s (484.15ms)
Speed.Dev.#3.....:  1213.5 kH/s (481.70ms)
Speed.Dev.#4.....:  1210.2 kH/s (482.47ms)
Speed.Dev.#5.....:  1220.8 kH/s (477.90ms)
Speed.Dev.#6.....:  1214.7 kH/s (480.94ms)
Speed.Dev.#*.....:  7285.8 kH/s

These benchmarks assume ideal conditions. Real-world speed may be on the order of half of this speed or less, depending on the type of attack.

As long as the rate at which candidate passwords are generated is high enough, and the native hashes-per-second rate possible due to the algorithm itself and its work factors (iterations, etc.) is slow enough, the length of the candidate passwords does not impact the guess rate.

  • Hello Royce. Thank you for the answer. Its a bit too technical for me, I must say. Why is it "designed to be slow"? And would you care, if you have time, to explain your calculations? – riseagainst Feb 23 '18 at 16:06
  • @riseagainst - Why it was designed to be slow is outside of the scope of your answer, and it would be unfair to change your question since it would make this answer incomplete. However, why PBKDF2-HMAC-SHA256 computations were designed to be slow, is to prevent brute force attacks. The technical details of why it is slow would be appropriate on some other StackExchange website, likely existing questions there, that have those details. – Ramhound Feb 23 '18 at 17:00
  • @Ramhound I think you mean question. Thank you for taking the time, I understand a little better now and found other posts about PBKDF2-HMAC-SHA256 that explain it better. Thank you Royce as well for your answer. – riseagainst Feb 23 '18 at 18:12

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.