Hi all again!
Interesting discussion, I’m enjoying it mostly, but do try to direct comments to the subject matter and not to the persons. We want these forums to be a nice place, and I certainly want there to be criticism – but on the technology, not the participants.
Although many users use AxCrypt for local device file encryption, as has been mentioned, there are many potential problems with that. AxCrypt was developed and intended for the scenario when files actually leave your physical device. For local device encryption, I primarily recommend full drive or volume encryption, such as BitLocker, VeraCrypt etc. It’s still useful for local file encryption in many scenarios, but it’s not the primary target use case.
AxCrypt 1 and 2 *has* been audited, several times, by entities competent in the field. Unfortunately, none of these reports are public, so you’ll just have to trust me on that ;-) Even better: Trust, but verify. I’d be more than happy if someone will find funding and organize a similar public audit as was done for TrueCrypt / VeraCrypt. For obvious reasons, even if I had the funds, I cannot do that myself.
The more effort that is spent in analyzing AxCrypt, the better it becomes. I am not at all afraid that some weakness might be found, since if they are there – we *really* want to know about it so we can *fix* it. In fact Stephen did find a problem, not in the actual algorithms or implementation of the cryptography, but in the dynamic calculation of the number of rounds to run the key wrap used to secure the session key (each file is encrypted using a unique key, your password or public key is used to encrypt that session key), causing it to hit the minimum (but still decent) 5000 rounds more often than it should. This is already fixed, and will be released later this week.
The sooner we become aware of a flaw, the sooner we can fix it. If it had been an issue on the level of the apparent level of the BCArchive implementation bug seemingly exploited by Stephen, we would have released a fix within 24 hours if at all possible – and we have a mechanism already builtin where we can alert all users with online access very strongly about the need to update. Actually we have a “reliability” warning we can trigger, and a separate “security” warning too.