Reply To: Key-wrap issue

[Stephen]

The minimum of 6 is lower down in the code, in the actual specifications of the key wrap. The higher levels enforce a minimum of 5000.

This is what confused me because it looked like 5,000 would always be the minimum (and possibly the maximum as well) even though 6 is stipulated elsewhere and you actually have a custom error message for display when the iterations are <6.

Very luckily the minimum is set at 5,000 and this mitigated the error. The bug wouldn’t affect users with long and secure passwords but if the guard wasn’t there then it could affect users with shorter passwords against an attacker using cloud acceleration or a very powerful system. Other software such as VeraCrypt uses 500,000 iterations but that is for SHA-2.

The part of 1 second / 2 second delays you’ll have to explain, because I don’t follow the reasoning. The idea is that performing the total number of key wrap iterations, should take approximately 50ms.

I inferred from the technical documentation that you were trying to calculate an approximate slowdown time in seconds based upon your 50ms calculation.

Now you have explained that you intend to compute 1000 iterations in 0.5 seconds it’s more clear but 0.5 seconds = 500ms (not 50ms) which is why I inferred from the technical documentation what I did.

• 50ms = 0.05 seconds
• 500ms = 0.5 seconds
• 1000ms = 1 second

I did some tests cracking my test file and I found that with the erroneous 5,000 iterations that it was cracking at 15 passwords per second and 0.6 passwords per second when I wrapped 300,000 [*] times.

[*] It was a few hours ago, I can’t remember this figure exactly.

Note: I intentionally throttled my processor speed because I was also testing the AES instruction set… hence the slow cracking times.

I see that you’ve promptly fixed this so this should resolve it when you release the next sub-version.