[AxCrypt SupportModerator]

Hello,

First of all – actually 2.1.1398 is the most recent version. It addresses an issue with how files are handled, but typically you’d see an error message if you had that problem, and it’s been very uncommon.

I’m a bit surprised about your descriptions – we’ve really not had any reports like yours. There has of course been issues, but typically they will result in an error message. I would really appreciate an snapshot report as I described above. It helps understanding what has happened.

I’ve not seen or heard of any problems with file-name collisions or special names. Collisions are supposed to be handled gracefully, either by renaming automatically, or by asking the user depending on the situation. I just tried the scenario with an existing clear text – a dialog is shown asking you to ‘save as’. Perhaps you did not notice this dialog?

The two error messages at the end are not good though. They indicate file corruption. This is typically irreversible. The first one is hard to say, it may also be that you have renamed a file that is not an AxCrypt-file. It should display the name of the file of course, that is a bug. Did you restart the computer or something while the encryption was running? The second message seems indeed like a file that was only partially encrypted and then the computer or AxCrypt crashed. In either case, there should be backup-copies available in the folder (named .bak). Otherwise, I sincerely hope you have backups, although I have the uncomfortable feeling the answer is no.

[AxCrypt SupportModerator]

Hello Harry!

Thanks for the feedback, although of course I’m sorry you’ve had such a bad first meeting with of AxCrypt 2.

We are entirely dependent on feedback like yours to improve the product, and which we did for a Beta period of almost 6 months with thousands of users. Nevertheless, new things pop up even now! For example, I do agree the ‘set password dialog’ should be more clear in stating the requirements. However, this is the first time I’ve heard of anyone not seeing the standard Windows error indicator icon! We’ll try address that as well.

Let me comment on your issues one by one.

1. Dialog to set a password. Thank you we’ll improve that. You can follow progress in our issue tracker.
2. No progress bar. There is, but I think I know what has happened. It’s a recently noted problem when encrypting/decrypting many files from Windows Explorer is very slow. The progress bar works – but this is before it even starts to work. We have a priority ticket on that too, but it’s in a private repository so I can’t post the link. Sorry. For now, I think drag and drop or using the toolbar buttons or menu selection will be faster and more reliable.
3. The problems with crashes here worry me the most. We’ve not received *any* similar reports. I’m also concerned when you say ‘system files’ – are you attempting to encrypt such?

Especially with #3 above in mind, I’d like to know what version you’re using. And, if I could bother you with a snapshot report after such a crash I’d appreciate it. Enable Debug mode under File | Options | Debug. Then in the Debug menu choose the Snapshot Report and follow the instructions.

Svante

[AxCrypt SupportModerator]

Hello John!

Please update to the most recent version. If that does not help, or you already have, send a screen shot of what’s not working or explain further.

Also, I respectfully ask that you please do not send the same question via different channels as you did with this one. This will make us respond slower, not faster, since we’ll be wasting time handling the same issue multiple times.

Svante

[AxCrypt SupportModerator]

Thank you Sputnik for you reasoned comments.

I am very much listening to the debate of V1 vs. V2, and I will work as well as I can to improve the experience for existing V1 users. I’ve already done quite a bit, but more can be done.

It surprises me a little bit about the ‘self decrypting’ files function. In my experience it just doesn’t work in practice. Does anyone here actually have a scenario where there’s any benefit or it actually works? Just about 100% of current e-mail servers and clients will block executables. I really think the standalone version is more than a substitute for the self decrypting feature. That being said, if there’s a real demand and it actually works, it’s not that hard to implement using the standalone version.

The offline functionality will probably be implemented in one way or another, but I really like the sign in metaphor where we associated the password with an identifier, even if offline. This reduces the risk of losing data due to mistyped passwords, and that’s a really good thing I think.

Version 1.7.3156 will indeed be useful for a long time, and please remember – effectively it’s been left on it’s own for about 2,5 years already.

Svante

[AxCrypt SupportModerator]

Thanks Laurel,

You ask many good questions that we need to be much clearer in our communication about – so they don’t need to be asked!

1 – What happens when the 30 day Premium period ends? Nothing, really. Premium features are no longer accessible, you revert automatically to the free version. No need for new downloads or anything. AxCrypt mostly works as usual, but without the perks of Premium.

2 – What happens with 256-bit encrypted files when the Premium period ends? Nothing, really. Of course you can still open them! We’ll never lock you out of your data because of a discontinued subscription. They will open normally, and remain 256-bit until modified and re-encrypted, in which case they will use 128-bit encryption instead.

3 – What happens with passwords saved in the Password Manager when the Premium period ends? Nothing, really. Of course you can still read them! We’ll never lock you out of your data because of a discontinued subscription. However, you can no longer update, add or delete new passwords. (You didn’t ask, but this was a good place to answer the question anyway!)

Svante

[AxCrypt SupportModerator]

Hello,

Thanks for your input – keep it coming!

Svante

[AxCrypt SupportModerator]

Thank Laurel for the response!

I’m also happy to see that the forums are working as they should, as a source of information, opinions and criticisms of AxCrypt.

To that end, and since it fits nicely in the subject topic, I was just reminded of the “10 Immutable Laws of security.”.

They are good laws to follow!

[AxCrypt SupportModerator]

Thanks for the feedback, RngFarAway!

If you wish to reconsider, do keep an eye on our blog, where I’ll be addressing some common questions about the design decisions around Version 2.

[AxCrypt SupportModerator]

Hello Edgar,

Not quite!

Here’s how it works, briefly, to encrypt a file.

1. A 128- or 256-bit key is generated with a strong cryptographic pseudorandom number generator.
2. The file is encrypted with this key.
3. The key is encrypted using an iterative algorithm called NIST AES Key Wrap, with the number of rounds determined by the speed of your device. I.e. the faster the computer, the stronger the key encryption is.
4. The key is also encrypted using your public RSA-4096 key we generated for you.
5. The key is also encrypted using the public RSA-4096 keys of people you have enabled key sharing with.
6. All of these versions of the encrypted key are included in the file, both at the start and at the end for redundancy.

Your private RSA-4096 key, which we store on the server for backup and device synchronization/initialization purposes, is encrypted with AxCrypt, using your password with the above procedure but with steps 4 & 5 skipped for obvious reasons.

Once you have signed in for the first time on a device, your private key is cached locally and Internet access is no longer required.

Hope this clears things up!

Svante

[AxCrypt SupportModerator]

Hello!

Thank you again for your feedback and interest!

You are right that we do have an issue with the intuitive feeling that it’s bad to have the password sent to a server.

We are considering this, but what we’re trying to achieve is decent security that is really simple to use. So, the ‘offline’ feature would have to be as simple. We’re not quite sure just yet how this would work, but we are certainly thinking about it.

Once again, thanks!

Svante

[AxCrypt SupportModerator]

Oh, and and about the “I’m not a Robot” thing. It’s called a captcha, and the purpose is to stop automatic scripts from posting garbage to our forums.

[AxCrypt SupportModerator]

Hello!

There’s no need. PayPal will convert as appropriately. We *are* looking at alternatives, but for other reasons. If you have any trouble, let us know!

Also, you don’t need a PayPal account (although they dearly like you to sign up) to pay. An accepted credit card is sufficient.

Regards

Svante

[AxCrypt SupportModerator]

You are most welcome. Good luck!

[AxCrypt SupportModerator]

Hello Wayne,

I’m afraid we don’t really support your scenario at this time. You can do quite a lot with the installation process, using standard Windows Installer commands and switches. It’s just a standard installer package, so all such tricks works, including forcing parameters etc.

However, right now we don’t have the ability to do what you’re asking with per-system registration. I’m not sure what your scenario is though – is the intention that the users are not to use personal passwords, but rather all have access?

If you explain a little more I might be able to answer in more detail about now, and future plans.

As for command line switches, not at this time, though we’re planning to add one for off-line installation. You’ll still need to add an AxCrypt ID though (an e-mail plus a key-pair – this is what’s done when it connects to our server), so it’s not going to be more convenient.

[AxCrypt SupportModerator]

Hello Sputnik,

The short answer to your question, is yes, 128-bits suffices.

The medium answer is that it’s really about your password. If you have a weak password you’re not using the full strength of the algorithm, and then it does not matter if it’s 128 or 256 or whatever. So, you need a really strong password. The problem here is that it’s actually quite hard to type and remember a password that is equivalent to 128 bits, not to say 256.

If you use our password generator the strong password is approximately equivalent to 95 bits, and the short about 30 bits, so you can take a long and add a short, and you’ll get full strength.

In my personal opinion the long password is sufficient for all reasonable and most unreasonable attacks. A government might possibly crack such a password with time and some luck (there’s some strengthening added to, so it’s really about 105 – 110 bits), but only at great expense if at all. Personally I doubt it. A real 128-bit equivalent is currently out of the reach for anyone, including governments.

Regards,

Svante

[Author]

Posts