[SvanteSpectator]

Hello,

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. We are very sad that a hacker has choosen AxCrypt as the tool to perform the ransom attacks that appear to plague mostly Turkey, and apparently in your case Ukraine.

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. This has been going on for a long time…

AxCrypt is a legitimate tool that a malicious hacker has choosen to use in order to commit his crimes. Neither AxCrypt nor we are the problem. The hacker, and the conditions that led the hacker to succeed is the problem.

[SvanteSpectator]

Hi,

We’ll evaluate the sign in / sign out options for the mobile apps as we go along, but right now we’re depending to a large degree on the inherent security of the device encryption capabilities since there are so many aspects of a mobile phone we can’t control without rooting it and doing all kinds of bad stuff. Even if we did sign out, without device encryption, there will be at least some information available for a persistent attacker that has physical access to your phone.

So – ensure that you are using device encryption and a pin or Touch ID or equivalent to unlock your phone. This applies regardless if you use AxCrypt Mobile or not!

[SvanteSpectator]

Hello Robin,

It is indeed a Premium-feature. Sorry, but if it’s any consolation every dollar that is paid for AxCrypt Premium goes into design and development of new features and platforms – the income goes right back into the software.

– You can explicitly sign out of the app. It remains signed in with essentially the same reasoning we have for the desktop app. See http://www.axcrypt.net/blog/leaving-computer-axcrypt/ for a longer dicussion about this. Briefly – use pin codes or Touch ID to lock your phone.

– We could do a partial finger print integration, and we may in the future, assuming that one signs in at least once in order for us to store the password in the phone but there are some fundamental differences between biometric identity credentials and the secret that is required for encryption. Also here, I’ve made a longer argument: http://www.axcrypt.net/blog/encryption-and-biometrics/ .

[SvanteSpectator]

Hi Julian and George,

As mentioned, yes we did remove that function because it promotes insecure user behavior, and also very seldom actually works. No major email provider will allow you to send .exe-files as attachments. A longer discussion is found here http://www.axcrypt.net/blog/avoid-self-decrypting-files/ .

However, if you for whatever reason cannot ask the recipient to download AxCrypt by including the link to the download page in the email with the encrypted attachment, why not just send the user two files? The encrypted attachment and the portable version of AxCrypt 2 (yes, it’s an executable, so it’s just as likely to fail as a “self-decrypting” archive).

[SvanteSpectator]

Sorry John, but I can’t help you out here… It’s all there in the source code, but we cannot provide help from AxCrypt.

Maybe someone in the community would like to jump in?

Svante

[SvanteSpectator]

Hello Derrick,

I am assuming the following:

– You are using AxCrypt 2.
– You have shared the file key with the recipient, by adding the recipient’s email address to the list of users the file is shared with.
– You have sent the encrypted file to the recipient somehow, perhaps via email or by sharing via a cloud storage provider.

The recipient then needs to have AxCrypt 2 installed on his/her computer and has a verified AxCrypt ID account and has set his/her password.

The recipient then double-clicks on the file, signs in to AxCrypt if required, and the file opens.

[SvanteSpectator]

Hi Shawn,

That’s the beauty of AxCrypt ID account which is based on public key technology.

When you change (not reset) your password for your AxCrypt ID account, *all* files previously encrypted with that AxCrypt ID account will automagically open with the new changed password.

—

Technically, this works because your AxCrypt ID is associated with a public key pair. Each file is encrypted with a random and unique file key. This file key is in turn encrypted and placed in the encrypted file. The file key is encrypted both with the original password using a symmetric encryption key wrap, but also with your AxCrypt ID public key.

When you change (not reset) your password for your AxCrypt ID account, essentially what happens is that you re-encrypt your private key of the key pair with the new password.

So, when opening a file when signed to your AxCrypt ID the following happens:

– Your private key of the AxCrypt ID is decrypted using your sign in password.
– The encrypted file key is located in the .axx AxCrypt encrypted file, and decrypted using the private key.
– The decrypted file key is used to decrypt the actual file contents.

[SvanteSpectator]

Hi Bruce,

In addition to the correct summary by Barry (thanks), I’d like to point that that 1.7.2976 and 1.7.3156 are essentially identical, with the major difference being a few updates to underlying libraries, and the removal of the Open Candy wrapper in the installer. 1.7.3156 is an entirely clean download. You should always prefer that over 1.7.2976.

[SvanteSpectator]

Hi Emily (and thanks to Barry for jumping in),

I’d just like to confirm what Barry’s saying – the key sharing feature in AxCrypt 2 should improve usability for your scenario, provided the group of users having access to a given file is not too large. But then again, if it’s say 50 persons – just how much security to do you imagine you’ll be getting with a “secret” password shared with 50 people?

The whole point of AxCrypt 2 key sharing is that you *can* share encrypted files with others *without* sharing any passwords. You do not need to give out your password. You just add the authorized viewers to the list of users to share the file key with.

If you try it out, I think you’ll like what you see and find that it’s actually a great improvement over AxCrypt 1 for your situation.

[SvanteSpectator]

Hello Bruce,

1. Yes, but why would you want to run 1.7.2976?

2. Not with different passwords, but each user can have his or her own password, and share the key the to file and open it with their own passwords.

3. Not at this time, IIRC. Shredding is a premium feature. This may change soon,

[SvanteSpectator]

Hello Mark,

I’m guessing that the error message mentions something like “GUID Mismatch” also.

When AxCrypt tries to open or decrypt a file, the first thing it does is check the first 16 bytes of the file content for a “magic sequence of values”, sometimes called a GUID. Each and every file that is encrypted with AxCrypt starts with the same 16 bytes.

This check fails for two known reasons:

1) The file is damaged. This kind of damage is known to occur when the file is encrypted with AxCrypt 1.x, and resides on removable media such as a USB drive, and that media is removed from the computer too quickly without using the “Safe Removal” feature of Windows. In this case, the file may not be completely written, and the first part of the file is lost. This does not typically happen with AxCrypt 2, because we’ve improved the structure of the file in this case to avoid this risk. That’s one of the major reasons AxCrypt 2-files are not quite identical to AxCrypt 1-files.

2) The file is in fact not an AxCrypt file. This typically happens when a user manually renames some file to end with .axx . This causes the file to be associated with AxCrypt, but when AxCrypt tries to open it once again the first thing it does is check those first 16 bytes. If the file then is not an AxCrypt file, you get that message.

[SvanteSpectator]

Hello Sugs,

Not sure I understand. You say you used “AxCrypt to encrypt some .txt documents”. If you did that with AxCrypt version 1, and then upgraded to AxCrypt 2 – you just enter the original password.

From our logs there seems to have been some confusion. You created an account, reset the password for the account, changed the password for an account, created a new account and finally recreated the original account. Also, you’re using an outdated version of AxCrypt 2, please download and use the most recent version from our official download page.

It’s a little hard to really say for us exactly the sequence of events – but what you need to do is to remenber the password you used when you first encrypted the .txt files. That’s the password that AxCrypt is asking for the file.

[SvanteSpectator]

This will not be responded to further by AxCrypt staff, but we do invite the community to help out! We posted a brief response as well here: http://www.axcrypt.net/forums/topic/use-the-source-code/ .

[SvanteSpectator]

Hi Zoran,

The subscription license covers one account (i.e. one sign in with an email) from any number of devices. So essentially it’s a per person, not per device license.

The person doing the key sharing must have a Premium license, but you don’t need to have Premium to be the recipient of a file with a shared key.

Hope this answers your question!

[SvanteSpectator]

Hello John!

Sorry, but generally we can’t give source code support. Perhaps someone else in the community would like to help?

A quick hint though – check the methods in class AxCryptFile, I think they will do more of what you’re looking for. As for the type registry, check out Program.cs – you’ll find all the required type registrations there.

We will be providing a SDK with sample code in the future, but we’re not there quite yet.

[Author]

Posts