[AxCrypt SupportModerator]

Hello Michael,

AxCrypt is file encryption software, not backup software. It protects your information from disclosure, not destruction. Backup protects your information from damage, and AxCrypt-encrypted files can be backed up like any other file.

“I tried saving the Password Generator webpage for use when my computer doesn’t have WiFi but the page doesn’t work. Why is this?”

I’m not sure about what you’re saying, but it seems you’re saying that a our web page doesn’t work when you’re offline. No, it doesn’t. That’s how web pages work, you visit a server on the web and it does cool things for you. Without Internet access, no access to our (or anyone elses’) server, and thus no function. That’s kind of the thing with the web… If I’ve misunderstood you, please elaborate.

[AxCrypt SupportModerator]

Hello G.D..

(Thanks Robin) – I think you also sent a support request email. We’ve responded to that as well.

[AxCrypt SupportModerator]

Hello Chris,

Please contact our support for this kind of issue and we’ll try to help you sort things out. When you do – please include screen shots of where you’re stuck (it might seem self-evident from your description, but it’s not!).

[AxCrypt SupportModerator]

Lightwind,

We’ll certainly post on the forum to start with, then social media, and later on the download page. We will not push out any notices via email etc until the actual release, so just stay tuned!

We want to start slowly and not get too many users at once, it will after all be a beta. Although the core code is as solid as the other apps (since it’s 100% exactly the same code), there will of course be some glitches and probably some lessons learned about the Mac as an environment since it’s new to AxCrypt.

[AxCrypt SupportModerator]

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.

[AxCrypt SupportModerator]

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.

[AxCrypt SupportModerator]

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

[AxCrypt SupportModerator]

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.

[AxCrypt SupportModerator]

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.

[AxCrypt SupportModerator]

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.

 

[AxCrypt SupportModerator]

Hello Edward,

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

[AxCrypt SupportModerator]

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.

[AxCrypt SupportModerator]

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

[AxCrypt SupportModerator]

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 .

[AxCrypt SupportModerator]

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.

[Author]

Posts