Forum Replies Created
-
AuthorPosts
-
Hello David,
I am not sure that it’s actually AxCrypt as such holding on to the USB drive. There are several mechanisms at work, one of them being Windows caching of data being written to a USB drive.
You can always try and really exit AxCrypt to see if it makes a difference. There are also various utilties and built-in windows functions to see just what program is locking a file or drive. Windows Resource Monitor and wholockme are two.
Hello Ella,
Thank you for reporting this. We’ve identified the problem, and it will be corrected in the upcoming release. If you email support, we’d be happy to give you 6 months complimentary service as a bug-bounty!
Hello Ella,
Thank you! We’ll investigate and see if the link is wrong. It can also be your system that is configured to not open links in a working browser. What we do when you click a button like that, is we launch the system-registered default handler for http URLs. If none is configured, or wrongly configured, it won’t work.
In the meantime, the link you want is: https://account.axcrypt.net/Home/Purchase .
Hello Ella,
Can you please take a screen shot of the dialog where you are trying to “renew”?
Hello basw,
Please check that you really entered the right email – we’ve successfully sent it three times from our part. Also check your spam.
Hello Dee Arch,
It is kind of fundamental that with a system that can both be online and offline, and be used both locally and via the web there can arise a temporary inconsistency of data. This is no different from any cloud storage provider that offers online access.
1) You create a file in the cloud.
2) It is synchronized to your device.
3) You take your device offline,
4) You use a different device to edit the file via the web.Now you have the password situation I described, but described in document file terms with any cloud storage provider. It’s just how things must work if you offer both offline synchronized access, and online access via the web.
That we do offer this functionality is just so you can be sure to have easy access to your files regardless of our existance on the web, or the access to the web.
Also, AxCrypt is designed so no internet access whatsoever is required to decrypt your files. All the information required to decrypt a file is in the file – provided you know the password originally used to encrypt it.
Hello VeryAngryUser,
First of all, I am very sorry indeed if the damage to your files is caused by AxCrypt.
Although it has nothing to with the problem at hand, I’d like to note that the workflow “right-clicking, AxCrypt, Encrypt/Decrypt” is seldom the most convenient. For applications that are document-oriented and associate with a given file type, double-clicking and letting AxCrypt handle the decrypt/encrypt operations is much easier.
You report two different errors, that may or may not be related, and may or may not be caused by AxCrypt. First some background to explain what these errors mean.
An AxCrypt-encrypted file is coded in a special way. First of all in all AxCrypt-files comes 16-bytes. Originally randomly selected, but the same for every single AxCrypt-encrypted file ever encrypted. This we call a ‘magic GUID’.
Then, follows ‘meta-data’, i.e. data about the file, in various encrypted sections. These includes the original date/time-stamps, the original file name, encrypted file sharing keys, and similar. These we call ‘headers’.
Then the encrypted data follows. At the end of the file, we duplicate these headers for redundancy and add a special keyed encrypted checksum to ensure that nothing has been modified in the encrypted data.The first error, “…not an AxCrypt file” means that the first 16 bytes of the file are not the ‘magic GUID’ we expect. This is most often caused by user renaming of files to end with .axx, although they in fact were not encrypted by AxCrypt. Historically we occasionally had this problem with AxCrypt 1.x in combination with prematurely ejected USB-drives and in some cases, dropped network connections to file shares. We do have not had any confirmed such incidents with AxCrypt 2.x, although there’s been a very, very few reports where we’ve not been able to determine the exact cause.
The second error “Invalid block type” means that after correctly identifying the first 16 bytes, when trying to interpret the headers mentioned above, we encountered a block type with an invalid value (note that we are forward compatible with new block-types, the structure is such that we can ignore them). In this case the block type (or header type if you like) has a value that should never happen, now or in the future.
The first, when noted in version 1.x, was caused by data never actually being written to disk because of lost contact with the file system. We’ve sturdied up this in version 2.x by always writing forward, never backtracking in the file. We also added the duplicate headers at the end, as a redundancy.
The second is, as you foretold, essentially a new one. I can’t recall at least if we’ve seen that before. We have seen reports of a similar sounding problem, where the decompression layer has problems, but once again this is once or twice for the entire lifespan of AxCrypt 2.x.
What I’d like to do next, is actually see some of these damaged files. Please remember, they are purportedly encrypted and the whole purpose of AxCrypt is to ensure that if the files are seen by someone else, they can’t be decrypted. I do not want to have your password. Just damaged, encrypted, files. If you are agreeable, please contact me via support and attach the damaged files, and also a full error report as described here: https://forum.axcrypt.net/blog/send-complete-error-report/ . The purpose of the full error report is to ensure we know exactly what you are seeing, and also seeing if we can find traces of crashes or other errors in the logs included (the AxCrypt log and the Event log).
Hello Dee,
If you’re getting a “bad password” then it means… that you’re probably not entering the right password!
Normally, the online password will be synchronized with the offline data, so you can sign in with the same password.
However, there are situations where a different password will be used offline than online – namely when you change the password online (either through another system, or via the web), and then try to sign in offline. I can’t see any trace of that in your situation though.
This should work as advertised, so either it’s a bug or there’s some misunderstanding. You are welcome to contact our support via email, and then we can request some further information and see if we can determine where the problem lies.
June 8, 2018 at 13:50 in reply to: Files encrypted with AxCrypt v1.7.3156.0 cannot be decrypted with later versions #10728Hello Francisco,
Fortunately, you are wrong! All newer versions of AxCrypt can decrypt all files encrypted with older versions.
You do need to know the password of course!
Perhaps you can be a little more specific about what happens when you do try to decrypt a file?
Hello Anna,
To share an encrypted file via email to someone else, you use the ‘share’ function in AxCrypt. You enter the recipients email address and the file will be encrypted in a way that the recipient can open it too. However, remember that the email address is just for identification (just like you sign in to AxCrypt with an email address). You still have to send the file itself to the recipient using your regular email software.
There are videos explaining all this on our web site, https://forum.axcrypt.net/ .
See reply in other thread. Please do not cross post.
Hello Jeff,
Just right-click them in Windows Explorer or in the main window list of recent files in AxCrypt, and select the option to decrypt them.
Hi Ryan,
We usually work with different “themes” of development. So, for example, for one period we did the mobile apps, then the Mac desktop. Currently, we’re focusing on business administration functionality mostly – so right now adding the command line and SDK is not top priority. As for preference settings, we’re really trying to keep that to a minimum…
Hello sergio,
It’s unclear if you are making a statement or asking a question. In either case, I personally do not know what you mean with “the motorola radio” or how it can apply to AxCrypt. Please elaborate!
Hello Peter,
It is hard to make super-simple software that also caters to every use case. We try to make it as simple as possible for as many use-cases as possible. We do maintain that the key sharing functionality is so much better than the shared passwords used with AxCrypt 1.
You can always turn of the “auto-upgrade” of old files, so you can maintain them unchanged in AxCrypt 1 format and with the old passwords.
Nobody with access to your computer can read any encrypted files as such, however, anyone with access to your computer with your user rights and permissions can install any software on it so if you allow that you are insecure by default, regardless of AxCrypt-version or other software used.
-
AuthorPosts
