[SvanteSpectator]

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.

[SvanteSpectator]

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.

[SvanteSpectator]

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.

[SvanteSpectator]

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

[SvanteSpectator]

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.

[SvanteSpectator]

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.

[SvanteSpectator]

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…

[SvanteSpectator]

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.

[SvanteSpectator]

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.

[SvanteSpectator]

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.

[SvanteSpectator]

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 7 years, 9 months ago by  Svante.
• This reply was modified 7 years, 9 months ago by  Svante.

[SvanteSpectator]

Hello Sugs (& Napoleon),

The problem seems indeed to be a case of a forgotten password. There’s no need to downgrade to 1.7 to try decryption there, version 2 will open old files too.

As Napoleon says, if you can narrow down the possibilities, a brute force attack may work. In fact, you may perhaps try it manually – just open notepad or excel and then systematically type all the variants you think likely and then try them one after another.

There are no limits in AxCrypt to how many times you can try a ‘File Password’. The sign in prompt, which interacts with the server if you’re connect to the Internet, does have a limit.

[SvanteSpectator]

Hello,

Thanks for all the feedback! We will be adding an option to always prompt for the password. You can follow and monitor the progress here: https://bitbucket.org/axantum/axcrypt-net/issues/186/add-option-for-requiring-password-every .

[SvanteSpectator]

Hi Paul (& Lucas),

I need to correct Lucas on one point. AxCrypt is a password based file encryption utility. The AxCrypt ID key pairs used are for convenience in sharing and managing passwords. You will not lose your encrypted data if you lose your key pair. You can *always* decrypt a file if you have the software and know the password that was used when the file was encrypted.

In order to ‘nuke’ AxCrypt completely, it generally suffices to uninstall it via the control panel. Nevertheless, there are scenarios where some user and configuration data could be left on the computer. AxCrypt uses the following locations:

%localappdata%\AxCrypt in the file system for user data. This is always safe to ‘nuke’, even with AxCrypt installed (temporary decryption is done here, so working files may be deleted if you delete this folder entirely, but the installation as such will not be damaged).

HKLM\Software\AxCrypt

and

HKCU\Software\AxCrypt in the registry for configuration data pertaining to the Explorer integration, and the Windows Installer engine.

(It also adds file some shell integration stuff elsewhere, but that has no impact whatsoever on the ‘nuke’ aspect, and also these are removed during uninstallation).

The standalone version of AxCrypt, which does not require installation, does not use the registry at all but only the %localappdata%\AxCrypt location.

[SvanteSpectator]

Hi Robin (& Lucas),

As Lucas says, no there’s no connection with AxCrypt. Lucas is just an engaged member of the community, for which we’re grateful. He’s in his full right to point out alternatives, and I am very much for an open, honest and objective climate in these forums so I’m perfectly fine with suggestions for alternative softwares or solutions. AxCrypt is not perfect, not in version 1, not in version 2. Nor is any other product.

We’ll be continuing to develop AxCrypt  and for this to go in the right direction, we need input – be it positive or negative.

As mentioned elsewhere, we will be providing the option to request the password every time as a result of feedback. We may indeed also implement some model of use which is closer to the version 1.x, but that remains to be seen. Lucas is of course right that the AxCrypt 2 model does open up a few more attack vectors, but in each case we judge the benefit to be worth it. We are trying to make a product that is really useful for a large number of users, and this means we have to make tradeoffs from a theoretical zero knowledge model, in order to make the product useful in practice.

Finally, AxCrypt is indeed mostly suited for data transmitted over the Internet (i.e. email attachments), or stored remotely (i.e. cloud services, backups). For local device security I do indeed generally recommend full disk encryption or possibly file system level encryption such as Windows EFS, which is often well complemented by file encryption such as AxCrypt. Using file encryption software (be it AxCrypt, 7-zip or MS Office built-in) leaves quite a few holes on a local computer, that are more or less impossible to plug in the softwares themselves (temporary files, swap files, wear levelling in SSD etc). These holes are plugged very efficiently by full disk encryption. Similar arguments, but even more so, apply to mobile devices.

So, our recommendation is to use some kind of device or full disk encryption for local device security + some form of file level encryption for remote storage and transmission (we think AxCrypt is a good choice).

[Author]

Posts