Key-wrap issue

[Stephen]

I have been performing various cryptanalytic attacks on a test file that I encrypted with AxCrypt.

Your technical documentation says;

As a brute force counter measure, key wrapping is done with at least 10 000 iterations, increasing the work effort with approximately 13 bits. The actual iteration count is determined dynamically, a typical value is 100 000 to 200 000, adding 16-18 bits of effective key-length.

When I investigated my setup I found AxCrypt to be employing 5,000 iterations on my computer. Judging from the AxCrypt source code you actually require a minimum of 6 iterations which is contrary to your technical documentation.

I don’t have a slow system but if your assumption is 50ms per key-wrap could you explain why there’s a 1 second delay on my system when it should be 2 seconds according to your technical documentation?

[SvanteSpectator]

Hello Stephen,

Thanks for contacting us.

First of all, the web site documentation was wrong. The minimum is 5000, and typical values are between 25000 and 100000. The reason is the editor inherited this text from the old site, it’s essentially a copy-paste issue. It is now updated.

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.

Now, more importantly, reviewing the code we note that the speed determination is slightly incorrect. The intention is to do batches of 1000 iterations until half a second has gone, and then use that to calculate the effective speed. The current code includes the key derivation in each such 1000 iterations – which in itself also includes a 1000 iterations of a hashing function. The net effect is that our calculation is off. But it’s still at least 5000.

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.

[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.

[SvanteSpectator]

Hi Stephen,

Yes, the fix is in and will be released next week. Thanks! If you’d like I’ll be happy to give you 3 months Premium as a small bug bounty token of appreciation.

You should interpret the 50ms / full keywrap as being equivalent to targeting a cracking speed of 20 passwords / seconds in the target system, using our code – which is not speed optimized in the sense for example hashcat is which can use GPUs for much higher throughput.

The target of 20 full keywraps / second is set so that in normal use and even on a much slower system (think mobile), it will still be fast to actually use for a user. We don’t want a multi-second delay to open a file for regular users.

So it’s a compromise between usability and strength. But, at a target of 20 / second, and lets say you can with GPUs, some work and a decent amount of money can reach 500x that speed, you’re at 1000 / second. That’s still pretty slow. If you use a password such as that recommended by us via our password generator ( the most complex ones we suggest are at approximately 75 bits ).  At 1000 / second, a crack will average a little under a trillion years. With a national security level budget you could perhaps increase that by a factor a million, in which case a single crack will average a little under a million years. For the type of use AxCrypt is made for (private and commercial information security), we believe it’s reasonable.

[Stephen]

Yes, the fix is in and will be released next week. Thanks! If you’d like I’ll be happy to give you 3 months Premium as a small bug bounty token of appreciation.

It’s an easy error to make. Apple made a similar mistake in iOS 10 when they inadvertently reduced the security of their backups by 2,500 times.

As you’re an open source project I’ll forego your offer of 3 months premium because you give your own time in developing AxCrypt. Thank you for the offer.

I and my colleagues will gladly help open source developers. With closed source software bugs I tend not to report them to the developers because of the differing laws across the world (and the rules on reverse engineering) and because they contribute nothing towards the community. There’s also a big monetary market in the forensics software community for closed source software bugs.

You should interpret the 50ms / full keywrap as being equivalent to targeting a cracking speed of 20 passwords / seconds in the target system

Okay.

The target of 20 full keywraps / second is set so that in normal use and even on a much slower system (think mobile), it will still be fast to actually use for a user. We don’t want a multi-second delay to open a file for regular users.

I was thinking of mobile processors when I was looking at the key-wrap. It would be a small improvement (but neither essential or critical) to allow the user to modify the key-wrap within the UI. If simplicity is what AxCrypt is aiming for then maybe not.

With a national security level budget you could perhaps increase that by a factor a million, in which case a single crack will average a little under a million years. For the type of use AxCrypt is made for (private and commercial information security), we believe it’s reasonable.

The fastest supercomputers are capable of cracking at around 3 trillion passwords per seconds and attacks are only getting better. For private and commercial security the base iteration count of 5000 is reasonable as of June 2017 but once your updated version is released this will offer better security.

[SvanteSpectator]

The fastest supercomputers are capable of cracking at around 3 trillion passwords per seconds

I’m guessing that based on password hashing, hashing algorithms are significantly faster than AES which is the basis for the iteration here. Nevertheless, given a computer which does 3 trillion AES keywrap iterations / second, the average time to crack one AxCrypt-encrypted file password as mentioned above with it’s own strength of about 75 bits, with the 5000 round minimum in effect, is about 50 000 years.
If you use an even stronger password, then of course you get more margin. After all – we’re actually effectively only using 75 out of the 256 bits available in the algorithm key with passwords of that style. (A little more to be exact, since there’s also the 1000 iterations in the PBKDF2 function). You should probably add a factor for that above, giving 50 million years. But it’s always good to be conservative!

As you say – attacks are only getting better, that’s why we use the current hardware to scale up the strength as hardware gets better, so we at least keep pace with that.

[Author]

Posts