[SvanteSpectator]

Hello Lightwind,

Yes, the schedule still holds. We’re finalizing UI design, doing internal testing and putting the finishing touches to it. Hoping to go public beta in about 2 weeks.

[SvanteSpectator]

Hi EX Trial User,

You’re right in that there’s a “window of opportunity” when a file placed in a synchronized folder may be synchronized before being encrypted, and subsequently deleted from the cloud.

The reason we’re not encrypting it immediately as it appears, is that we ran into a lot of usability issues when we did it that way, due to the way AxCrypt interacts (or actually does not interact) with the operating system.

A simple scenario to illustrate the point:

– You open Word, write something, and save it to the secured folder.

– AxCrypt immediately encrypts it. This means the file “My Stuff.docx” disappears and a new file “My Stuff-docx.axx” appears.

This causes Word to become really confused, because it thought it just saved to that file.

In the future, we may implement a variant of the Boxcryptor technology with a kernel mode driver and intercept the actual file system calls. However, that increases the complexity very much and causes loads of other potential issues which I think users of such implementations will attest to.

We have some other ideas on how to retain our user mode integration model, and still avoid the issue you are describing.

In actual practise, the transient existence of a plain text copy in the cloud is not often the real problem. Nevertheless, you are right that it may indeed appear there if the cloud storage synchronization agent is efficient and fast.

[SvanteSpectator]

Hello Anne,

For this I think it’s best if you contact our support, and also include a full error reports as described here: https://forum.axcrypt.net/blog/send-complete-error-report/ .

[SvanteSpectator]

Hello Terry,

Thank you for that additional information. It’s also just yet another indication why self-decrypting .exe is a bad idea.

What happens is that the AxDecrypt.exe (which is the decryption software that makes up the code of the self-decrypting file) *is* actually digitally signed by us, but since it has to carry a data payload as well (the actual encrypted file) the operating system may treat that as an incorrectly signed file. We cannot sign the full file with the data payload because there’s no way we can delegate that operation, and we would not want to even if we could since we’d not want to sign something we did not have control over. That’s the point of digitally signing it, we take responsibility for the contents.

[SvanteSpectator]

Hello Flashfox,

You are right. Self-decrypting .EXE is not supported in version 2. In it’s stead, we have a fully featured standalone portable application. The only difference from before is that we don’t “physically” append the data to the executable, so it’s two files.

You always need AxCrypt on the target computer. The “self-decrypting .exe” of AxCrypt 1.x is just AxCrypt with the encrypted file appended. It’s literally exactly the same as the following MS-DOS command line command:

copy /b AxDecrypt.exe+SecretFile-txt.axx SecretFile-txt.exe

So, yes, you have AxCrypt on the target computer. Now, with AxCrypt 2, we just don’t do the above so instead you send / store AxCrypt-2.1.1494.0.exe (or whatever version is current) and SecretFile-txt.axx as two separate files.

See https://forum.axcrypt.net/blog/avoid-self-decrypting-files/ for details about why we have done this change.

[SvanteSpectator]

Hello Flynn,

First of all – AxCrypt 1.x is unsupported unmaintained software. That being said, as long as you’ve not restarted the PC the file is still available in the temporary location mentioned in earlier posts.

 

[SvanteSpectator]

Hello Edward,

Look here https://forum.axcrypt.net/axcrypt-brute-force/ and contact us if you think it’s worth a try.

[SvanteSpectator]

Hello Barry,

We’ve updated the app. Try version 2.1.163 or later, it should not have any more problems with large files. It may take a few minutes from this post for the download to update.

Once again, thanks for reporting.

[SvanteSpectator]

Thanks Barry, we’ll have to look at that.

[SvanteSpectator]

In order to provide us with detailed information to help us help you, for this situation we’d like a full error report. Please follow the detailed instructions here: http://www.axcrypt.net/blog/send-complete-error-report/ .

Please send this to support att axcrypt dott net .

[SvanteSpectator]

Hello Geoffrey,

From our logs we can see that you first set the password, then changed the password twice and then reset it on April 7. On April 23, you once again issued a password reset. Then, the next day on April 24 again a password reset.

It’s not entirely clear what stage you did the re-encryption mentioned, but there are no less than 6 different passwords used during three sessions that we can see. We don’t see much, but password changes and resets while online we do see (but not what the passwords are). This is exactly why we do log this – so we can help identify just what has happened!

So, what has happened is that you encrypted the files with one password, then issued at least one password reset after that.

You’ll have to think back on what passwords you used on these occasions, and one of those is the password requested by AxCrypt.

[SvanteSpectator]

Hello Barry,

Thank you for reporting this. We are not aware of any issue with the brute force software and certainly not based on file size. If you have some sample file you can share with us, please contact support and we’ll look into it.

[SvanteSpectator]

Hello SF,

Since you also sent an email, I’ve responded there as well. Please decide which channel you prefer, we can’t do both.

This is how AxCrypt works, it decrypts the files temporarily to that location, and keeps them there until it’s safe to remove them. If you delete them manually, that may cause problems.

If you have files there, and the ‘broom’ icon is not red and active, please let us know.

[SvanteSpectator]

Hello Kent,

I see you switched to the Premium support channel, which I was going to suggest anyway. So we’ll respond there.

 

[SvanteSpectator]

Hello Edward,

Right, now I understand. The dialog is there because the file password is *not* the same as your sign in password. The tooltip is there to help you realize that it does not make sense to enter the sign in password again, because the whole reason for the file password dialog is that the sign in password does not work.

I’d certainly ask if you wife has opened and modified the file recently, since that will re-encrypt the file with her password. To share a file like that, that’s what we have the key-sharing feature for. Setup up the file to be shared with both of you, and all should work without problems.

[Author]

Posts