[SvanteSpectator]

Hello Chuck,

Don’t think the AxCrypt.exe as such was “corrupted” – in that case it would not start at all.

When we talk about sharing in the subscription plan, it’s about key sharing embedded in the files. We are not a cloud storage provider, so no files are stored on our servers. What we do store are encrypted passwords in the password manager, and keys used to facilitate the key sharing function.

[SvanteSpectator]

Hello Joseph,

It seems very strange that AxCrypt tries to write files to the root of C:\ . Is the original file located there? If so, you should move it somewhere else, like your documents or desktop. Do not store and work with files in the root folder like C:\ .

[SvanteSpectator]

Hello Chuck,

Event 1) and 2) in your description are as expected and normal.

That AxCrypt might hang is of course possible – we’re not perfect, and AxCrypt like any other software has bugs.

What I find less likely is that AxCrypt single-handedly would affect your system post-reboot. It does not start automatically. You’re running the stand-alone version, so it does not even add itself to Windows Explorer.

I do not know anything about Norton except that as opposed to stand-alone AxCrypt it belongs to a class of software that actually does run automatically and injects itself into critical processes of Windows.

The point here is that while AxCrypt of course has bugs, they can’t really impact you when it’s not running. You can *use* AxCrypt to cause problems, for example by encrypting system files with AxCrypt (although we do try to detect and stop it from happening too easily).

Anyway, I am sorry you’re having problems but glad you seem to have them resolved for now.

[SvanteSpectator]

Hello Chuck,

Yes, the locked file message should come from AxCrypt. It’s AxCrypt who tries to open the file – and finds that it’s locked for sharing, and then displays the message in question.

I sincerely doubt that the cause of these issues is the standalone AxCrypt software as such. It’s just a single .NET executable, running without any special permissions, and doing nothing special. No, it does not write the registry.

If you kill the software with Task Manager (it should really just be easy to kill) or for that matter reboot and don’t start it, it does not and cannot affect your system in anyway. It’s just a passive file sitting in your file system. It can’t do anything unless you click it to run. No matter how problematic it could be – if it’s not running it can’t do anything to your system.

Do ensure that the software you’re getting comes directly from https://forum.axcrypt.net/ and no-where else, and that the digital signature by AxCrypt AB is correct.

[SvanteSpectator]

Hello Chuck,

You have understood the difference between standalone and installer version perfectly.

The problem with other software locking a file is that the file is locked. It’s not so much that AxCrypt is stopped from decrypting it, it’s that any other software than the one doing the locking is prohibited from modifying or deleting the file – which of course includes AxCrypt. Most softwares will let go of a file once they are done, but some are not so easy to understand when they really are done…

The subscription version offers quite a few additional features. Please check out https://forum.axcrypt.net/pricing/ for a comparison chart.

[SvanteSpectator]

Hello Chuck,

This typically means that the file is locked by some application or another. This utility: http://www.dr-hoiby.com/WhoLockMe/ can help find out just which one. The home page is ugly, the software is old – but has worked really well in the past. I have no relation to the developer, but I have used it personally.

(It’s also possible to do the same using the resource monitor, but it takes a little more skill, but it is built-in. The following description is for Windows 7, but should work in a similar way for Windows 10: https://www.winhelponline.com/blog/resource-monitor-find-process-locked-file-windows-7/ .)

[SvanteSpectator]

Hello artur,

Sorry to say, but briefly: your files are probably lost.

You appear to have encrypted the key file with Windows EFS, and then lost the keys to the EFS encryption by way of the re-install. This is probably the single most common cause of data loss in Windows – encrypting files (not just AxCrypt key files) with EFS and then re-installing Windows or losing the original installation in some other way.

I must also mention that we do display a clear warning to print out a physical copy of the key file when you create one. But, as many don’t do this, the key file option has shown itself to be too dangerous so we do not have this in AxCrypt 2. AxCrypt 1, which you’re using, is obsolete and unmaintained since several years.

Once again, I am sorry to be the bearer of bad news, but this is what seems to be the situation.

[SvanteSpectator]

Hello Dave,

To add to what Raja said, which perhaps did not answer your question fully:

At this time, you should probably not be using AxCrypt if you don’t trust our implementation that actually does transmit the password to the server. We are considering using a challenge-response type of sign in mechanism that avoids this – but the problem is…

It’s really all about the trust you put in us. While the theoretical model is certainly “more secure” when the actual password is not transmitted, the practical implications are such that many users will lose the ease of use that AxCrypt has.

Remember that you will be using the password locally – and that’s really the weak part of the chain… Your device is likely used for general purpose browsing and working, including downloading and running softwares from the Internet (such as AxCrypt).

Our server, which you under no circumstances want to send the password to, is a locked down server running only essential software, and with very limited capabilities. We never store the password in reversible form. The additional attack vectors created by this architecture are (simplified):

1 – The transmission over SSL. If that is compromised, you and we all have bigger problems…

2 – Bugs/malicious code in our code. You already trust us by definition by running our code locally.

3 – External attacks targeting our operating environment. Definitively possible, but to actually retrieve a password transmitted requires the attacker to be able to inject arbitrary code in our application environment – without breaking our app. Possible, yes. Likely, no. Requires skill and resources beyond a private enterprise, if successful even then. A government may do so by simply forcing physical access to our server, but even that is unlikely to go unnoticed. It would require a major operation, and we’re somewhat if by no means fully protected by having all our servers physically in Sweden. We do not use cloud servers, or shared servers. Only servers physically owned and operated by us, but located in secure data centers.

AxCrypt is intended to achieve a high level of protection against malicious, private and commercial, attackers. However, governments have other ways to get what they want – and if you’re doing things that are illegal, we’re not your tool. In fact, the terms of use state that you are not allowed AxCrypt for illegal purposes. That being said – a normal criminal investigation will be stumped by AxCrypt encryption. A security or intelligence organization of a major world power, have as mentioned other cheaper and simpler ways at its disposal. Google rubber-hose cryptanalysis for example…

[SvanteSpectator]

Hello Tamer,

I am very sorry to hear that you apparently are the victim of a hacker ransom attack against your files.

However, please understand that AxCrypt is just a tool that is used by millions of legitimate users for good purposes. I am very sad that a hacker has chosen AxCrypt as the tool to perform the ransom attacks.

Unfortunately in this case, AxCrypt is based on strong encryption, and it is generally not possible to crack the encryption.

What you must do is contact your local police, and have them follow the money and Internet trail to the hacker. Since others appear to be in the same situation, you may want to contact media in order to make this problem more widely known, and also gain the possibility of a group action of all the victims against the hacker.

We cannot help, we are in no way involved, and there is no way to open the files without the passphrase used.

Please read http://blog.axantum.com/2012/07/axcrypt-used-for-ransom-attacks.html for a longer discussion of what I know about this affair.

Also, please don’t cross-post (posting the same text in many places)!

[SvanteSpectator]

Hello Pamela,

Yes – use of a previous version on a different PC will look like a downgrade – we only store the most recently used version and the previous version.

The password is actually sent (but over an encrypted connection) to the server, and is then verified there if it matches or not, in an equivalent manner as is done locally. In neither case do we store the password as it is or in a recoverable form locally or on the server – except in briefly in memory on the server, and during a valid login in session locally.

The synchronization happens every time – although the net effect usually is nothing happens. But there are many scenarios where such a sync is required – even if the sign in is immediately successful. A slightly constructed, but simple to explain, scenario is if an account is password reset – to the same password as was originally valid, directly or indirectly.

Our servers never see or store any part of your encrypted files. This is all done locally on your device.

The disadvantages of operating entirely offline is among other things that you won’t get that sync done (effectively a backup of your key pair(s)) and it’s much less convenient. Also we won’t be able to update your license if you have a paid subscription.

[SvanteSpectator]

Hello Chris,

Very sorry for the long delay in responding, I missed this message.

The password manager is a general purpose password store for all kinds of personal passwords and secrets. As you probably know it is good security practice to use different passwords and pins for all different accounts you have. The password manager is a good place to store such secrets so you can keep track of them.

[SvanteSpectator]

Hello Pamela,

Yes, it’s possible to use AxCrypt entirely without online services, but it’s not something we really support or recommend.

The comment about online / offline password getting out of sync is only related to signing in to the app.

Your statement “With the Always Offline option invoked, Axcrypt does not recognise my password … With the offline option deactivated, my password is recognised” should not be the whole truth. Here’s how AxCrypt works in the respective situations:

Online:

1. You type a password to sign in, let’s say “MyPassword”. AxCrypt send a request to our server with that password (encrypted), and our server verifies that this password is indeed the password set for the online account.
2. If ok, AxCrypt synchronizes information with the server, including the hash of the password (a way to verify the correctness of the password, without storing the actual password).
3. AxCrypt remembers the actual password in the program memory.
4. You try to open a file by double-clicking it for example.
5. AxCrypt now uses this remembered password and tries to decrypt the requested file.
6. If successful, the file is decrypted and opened.
7. If unsuccessful, the file can’t be decrypted, and AxCrypt opens a new password dialog asking you for the file password.

Offline:

1. You type a password to sign in, let’s say “MyPassword”. AxCrypt verifies the password against the locally stored hash mentioned in step 2, above.
2. If ok, AxCrypt remembers the actual password in the program memory.
3. You try to open a file by double-clicking it for example.
4. AxCrypt now uses this remembered password and tries to decrypt the requested file.
5. If successful, the file is decrypted and opened.
6. If unsuccessful, the file can’t be decrypted, and AxCrypt opens a new password dialog asking you for the file password.

The out of sync situation can happen for example if you change your password online, perhaps using the web, and then use your computer offline without connecting to the Internet. In this situation, the offline password is the old unchanged password – so if you try to use the new password it won’t work because the offline app has not yet been synchronized.

Once you successfully log in online, the offline password should be updated.

So the question is really – at what stage does AxCrypt not recognize your password?

Looking at the logs, it seems you have a pending password reset request, and also that you downgraded from 2.1.1560 to 2.1.1547 – but the current version is 2.1.1573 . Can you tell us some more about the sequence of events, and best of all – screen shots of how it looks when it fails? Also, do please update to the most recent version.

[SvanteSpectator]

Hello Donna,

It’s hard to say exactly without seeing the details – but you write “it is saved onto the desktop” – that doesn’t sound like you’ve actually installed AxCrypt. Please check the getting started information and videos at https://forum.axcrypt.net/ .

You do need to actually install AxCrypt. Just downloading the software or installer is not enough.

[SvanteSpectator]

Hello Neil,

The progress bar will be improved. The main problem is that it’s not possible to quantify the total amount of work (number of files / number of bytes or whatever) without actually enumerating all the work that needs to be done. That can take considerable amounts of time. Also… AxCrypt does things on multiple threads, and it displays each thread as a sub-division of the progress bar.

All that being said, you’re right, it needs improvement. Thanks for reminding us!

There is no simple log file of work done, that’s actually a good idea. We do have a log, but it’s more for troubleshooting purposes. Thanks!

[SvanteSpectator]

Hello,

Yes it is! Just disable your Internet connection and try it out.

[Author]

Posts