[AxCrypt SupportModerator]

Hi eddie,

The file was then damaged during the update today. Hopefully you have a backup of the encrypted file?

The problem here was not caused by the update of AxCrypt, since the first thing that happened was that it was not recognized.

This type of damage can happen when a file resides on a removable drive, such as a USB stick, and it is removed without using Windows Safe Removal. Resetting or crashing the system can have the same effect. It has nothing really to do with AxCrypt, it’s how Windows works.

In fact, with AxCrypt 2, we’ve done some things to mitigate this kind of situation so that if it does happen, chances are at least part of the file can be recovered. In the end though – if something happens stopping Windows from actually writing file contents to a drive, that file will be damaged.

[AxCrypt SupportModerator]

Hello eddie,

This has nothing to do with the upgrade as such. The file in question is indeed either not an AxCrypt file, or more likely unfortunately, damaged to the point where it is no longer recognizable as an AxCrypt file.

When did you last open the file in question, and more importantly – when did you last modify it?

[AxCrypt SupportModerator]

Thank you Hans!

[AxCrypt SupportModerator]

Hello Świętomierz,

The root certificate is not the main issue for an attacker here. Although I do not use Kapersky, from your description it’s fairly clear that what it does is install itself as a proxy locally in your computer.

When you connect to for example our server using SSL that proxy can’t see and inspect the encrypted content unless it actually decrypts the traffic. Since it’s configured as the system proxy, what actually happens when you connect to https://forum.axcrypt.net/ is that you are connecting to your proxy. This is where the installed root certificate comes in (this is likely a unique certificate generated locally just for you). The proxy now generates a certificate for “https://forum.axcrypt.net/” and signs it with that root certificate. Since you have previously installed the root certificate as “trusted” in your computer, your browser will now trust the connection.

What the Kapersky software does is essentially a “man in the middle” attack in your own computer.

The connection over the Internet then proceeds as usual, except that it’s Kapersky who will be validating the certificate presented by “https://forum.axcrypt.net/” and establish the encrypted connection over the Internet. If the Kapersky software is implemented as I am guessing above, this means that the Internet connection is just as hard to listen in to as before. It does require quite a lot from Kapersky to do the connection negotiation properly, I would rather trust Microsoft or Apple etc for this (if I have to trust someone, which I do for this).

Mounting an attack against an SSL connection over the Internet is no small thing, even if the server (i.e. http://www.axcrypt.net) certificate is somehow compromised. The attacker needs access to the data stream, and that requires some actions that are really hard to achieve unless you’re a provider or in national security. The provider would normally not be interested, unless its being forced to comply by national security – which is what has happened in a few known cases in the US.

[AxCrypt SupportModerator]

Hello Florent,

You’re quite right – and the FAQ you’re referring to is outdated. AxCrypt 2 has all the basic technology in place for key recovery (AxCrypt 2 works very similar to how SecureZip does in this regard, where we have a public key based system for sharing of encrypted files. This can ‘easily’ be extended for key recovery.) It’s scheduled to be released in 2017 along with other business-related functionality.

[AxCrypt SupportModerator]

Hello Świętomierz,

This is so sad – that Kapersky and similar will actually inspect SSL traffic and encourage you to trust their root certificate. I personally do not think that this should be done in that way. Anti-malware should only offer to intercept in the case of a non-trusted certificate being used for SSL to start with. The way it’s now is totally backwards, and just opens up for any number of scenarios. The thing is – if you connect to us for example, with a *trusted* certificate, that’s just the point. You trust us! Kapersky should not distrust your trust of us by way of an SSL certificate.

It’s such an obvious attack vector for malware: “Hi, this is Kapersky – I noticed you have not trusted our updated root certificate. Please click here to update.” If I send you an email with this content, and you’re using Kapersky chances are you’ll be tricked.

Thank you for reminding us and pointing this out. We do not do so currently, but for the apps we should really add another layer of encryption there. We can’t do it for web access, but that’s a different story.

And, yes, if you want to avoid AxCrypt using Internet at all, disable it by way of the –offline switch or the menu option “Always Offline”. This has some other not-so-good side effects though. You won’t be notified of software updates, and if you change the password, it won’t get synchronized with other devices.

[AxCrypt SupportModerator]

Hi Bobby,

This is intentional behavior by design. Please read https://forum.axcrypt.net/blog/leaving-computer-axcrypt/ for a longer discussion about this design.

[AxCrypt SupportModerator]

Hello Wayburn,

To run AxCrypt online, start it from the command line with the switch:

–offline

(Note the double dashes).

I sincerely doubt that disconnecting from the Internet would cause a password error. Please verify this by copying and pasting the password you know is correct, with and without Internet.

Finally, if you’d like further help, please send us a complete error report like this: https://forum.axcrypt.net/blog/send-complete-error-report/ .

[AxCrypt SupportModerator]

Hello Anonymous,

Can you perhaps explain more about this?

It’s important to understand that AxCrypt does not encrypt files in Dropbox. It encrypts files on your local PC, that will be synchronized to Dropbox. So, when you encrypt an existing file on Dropbox, it’s possible to recover the original from Dropbox. This is because Dropbox keeps backups and from the Dropbox point of view, when we encrypt a file in a synchronized folder, this is seen as “Delete the original” + “Create a new file”.

You should be careful to encrypt files in your Dropbox before they are ever synchronized there unencrypted. Once they are synchronized, you are entirely in the control of Dropbox and it’s only at their discretion the original data is ever removed. We can’t do anything about that.

[AxCrypt SupportModerator]

Hello nobody,

I’ll agree with Gordon – it’s what AxCrypt is intended for. I also agree with his suggestion, if you just want light-weight access control on a shared computer – setup your own Windows account on it and don’t let your bother use that account. No extra software needed, and it seems to fit your use-case. It’ll also keep bookmarks, search history etc separated from other users of the computer. It won’t stop a good hacker or a forensics expert, but it should stop your brother, and definitely make it very clear to him that your stuff is private.

[AxCrypt SupportModerator]

Hello Martin,

You’re almost right. When you change the password, all files encrypted with the old password will open automatically. This will work as long as you have been online with AxCrypt at least once with the device in question after the change.

If you’re decrypting on a device that has not been online with AxCrypt at least once, yes, then you can open the file with the original password that was in effect at the time of encryption.

Now to your questions:

1) The same rule applies for permanently decrypting a file. The passwords will work as above. So, if you’ve changed the password and have been online, the new one will work fine.

2) If you do change your password on a monthly basis (which would *not* recommend as a security practice!), you’d wind up with files from a given month opening both the the current password whatever that is ,*and* the password of the month when the file was encrypted. There’s no password nightmare here, since you can open them with the single current password at all times – as long as the device you’re doing it on has been signed in online since the change.

I really think you should consider your password changing strategy, I don’t see it as adding any security. On the contrary, it seems that it would cause a real problem in trying to remember that new password every month, or even worse – you’re using some kind of system to modify your password from month to month. Get a good, long and strong one, and stick with it until you have any kind of reason to suspect that it might be subject to a leak. If this does happen, then you should certainly change your password, and re-encrypt all files that you can. If it does happen, the risk is great though that the attacker has already had access to your files, and copied whatever might be of interest…

[AxCrypt SupportModerator]

Hello David,

When you are logged in to your PC *and* you are signed in to AxCrypt – then you (or anyone else with access to your PC) can access your encrypted files on your PC. Which makes sense, since you are you and anyone else who can access the computer as if they are you, are… well.. you from the computers point of view.

If you have a screen saver, or the computer goes to sleep, or your log out of Windows, or you sign out of AxCrypt – you or anyone else with access to your PC will need to know your AxCrypt password in order to decrypt and open your files.

In the case of a file that is stored on OneDrive, in no situation is the file accessible except in it’s encrypted form from your OneDrive account on the web or from another computer.

If, for example, you are working on your PC with a file on OneDrive, and at the same time a hacker managed to access your OneDrive account from their own computer or the web, all files there will always remain encrypted.

Files are only decrypted locally on your PC when you open them with AxCrypt. Never remotely in your cloud storage.

[AxCrypt SupportModerator]

Great to hear Paul,

A final comment on a question posed by you and others about why we ask for an email adress even in offline mode.

There are several reasons for this:

1) Our assumption is that the state of offline is mostly temporary. Once we’re online again, we’ll use the email to attempt to synchronize with the server.

2) We will support several AxCrypt users under one Windows Login (or under one iOS / Android user etc) in the future. In this case we need some kind of ‘user name’ to separate them, and it just seems reasonable to use the same type of identifier we use for normal online operation. It’s also easy for people to remember and recognize, and requires no ‘invention’ by you. If we asked you to “chose a user name”, many would be confused by that instead. And, we still have 1) above.

[AxCrypt SupportModerator]

Hi Sugs,

We can send you a program that handles some situations. The problem is that it’s really hard to write a general purpose software that can interpret instructions like “a sentence with three or four numbers and special characters in the end“.

The software we have can do it to a certain degree, but it’s not entirely simple to use. We cannot give much support either, so what you should do is to encrypt a new file with a known password, and then try the brute force software out with a suitable pattern and verify that you understand the operation, and that it does find the (known) password as expected.

Then you can do the real search. Be prepared for a long wait if there are many possible combinations to try.

Please send an email to support@axcrypt.net and we can arrange for you to receive the software.

[AxCrypt SupportModerator]

Hi Paul,

Trust, but verify, right?

AxCrypt (the client) will fallback to offline mode even during first time registration if our servers are unavailable, for whatever reason (no Internet, we’re out of business, we’re under attack etc).

So, if this happens, we’ll generate an AxCrypt ID (the key pair) offline, and at the first opportunity (if ever) we’ll synchronize with the server and update the key pair at both ends. If our servers are never reached, it all works without them. You just need to know the password used to encrypt older files. If it’s different from the one you set during the offline registration, you’ll be prompted for the file password.

Here are a few screen shots from AxCrypt being installed from scratch on a computer where the DNS name resolution was modified so that ‘account.axcrypt.net’ (our server) went to empty space – i.e. the same effect as if our servers are down and non-responsive. The same thing happens if DNS cannot resolve the name at all, or if the connection is blocked by a firewall, or if your computer just does not have Internet connectivity.

After entering an email in the dialog you show (that just has to ‘look’ like an email), you come directly here, no prompt for verification code:

Then, after setting a password, we’ll generate a 4096-bit RSA key pair locally. This takes time.:

Finally, after signing in, it’s as usual – but you’re offline. Check the title bar.

Now all works as normal, except you’re offline and your key pair is locally generated. But you can still open any file as long as you know the password originally used. As mentioned – the key pair is used for convenience and for the key sharing feature, when you share encrypted files with other recipients.

As mentioned, as long as you have the software and know the password, you do not need our servers to even exist on the Internet, much less any Internet connection at all in order to continue to use AxCrypt.

• This reply was modified 9 years ago by  AxCrypt Support.
• This reply was modified 9 years ago by  AxCrypt Support.

[Author]

Posts