Forums Community Unhappy with version 2 Reply To: Unhappy with version 2

#7854 Reply

Svante
Spectator

Hello Captain Quirk!

Yes, we know there’s demand for those features. There are several reasons why we don’t meet them:

1) Version 1 still meets the requirements! As is.

2) We don’t think it’s a good idea, i.e. we do not want to promote bad security practices. Self-decrypting files for example.

3) We don’t have the resources, and we’re not getting any income back at all from work done on version 1.

4) If there really was a high demand, the source code is available, so anyone with the appropriate skills can fix it.

As to your specific request about the use of SHA-1 in AxCrypt 1, it’s non-trivial to fix since it breaks compatibility. Then, as far as I know, our use of SHA-1 is not among the scenarios where it’s a problem. I.e. in our specific case, SHA-1 still works fine and is still a good match for the purpose. That being said, I’d never recommend using it in a new product of course, but there’s not enough incentive to update our old software. If there was a real risk for security breaches, then it would be a different matter.

The problem with SHA-1 is that a collision attack is becoming economically feasible in 5-10 years. This, however, does not really pose a very large security risk for AxCrypt. We use SHA-1 for password derivation (here the attack is meaningless), and for HMAC-SHA-1, a keyed verification of the file integrity using SHA-1.

Let’s assume for the sake of argument that it’s trivial to compute a SHA-1 collision and thus our HMAC is easy to forge. What is the effect? What can an attacker do?

He or she can modify your encrypted data, without AxCrypt flagging this immediately.

What’s the effect? That someone can destroy your files, and you won’t notice it until the decompression fails because of the ruined data, or you find garbage in your word or excel file, or it won’t load etc.

The net effect of the above worst-case scenario for SHA-1 is that the strong HMAC reverts to a regular checksum. I.e. a sanity check of the contents, but not immune to nefarious modifications. Bad enough, but not bad enough to warrant an emergency fix in essentially unmaintained stable software.

Remember that the data is still encrypted, and it’s the encrypted data that can thus be modified, without a strong check. Your data is still securely encrypted.

This is completely different from the more important reasons to stop using SHA-1 SSL certificates for example, where a collision may enable you to forge a certificate, and thus produce false certificates.