Forum Replies Created
-
AuthorPosts
-
Hello Val,
The mention of “GUID mismatch” makes me think that you are using the old AxCrypt 1.x. This software has been deprecated since several years, and is no longer supported nor actively maintained.
In AxCrypt 1.x this could sometimes happen when the encryped file resides on a removable or remote media, and the connection is lost or the removable media is forcably removed without using the Windows “Safe Remove” feature. This in turn could happen because of an in retrospect unfortunate design decision.
AxCrypt includes a keyed HMAC to ensure the integrity of the encrypted file, i.e. that it cannot be modified without detection. In the AxCrypt 1.x file format, this HMAC was placed in the headers, at the start of the file. But, since it requires encryption of the entire file to be calculated, this design required AxCrypt 1.x to “rewind” the file and rewrite the headers at the start of the file. This was done by keeping all the headers in memory, and just leaving space for them at the start before rewinding at the end and writing all headers.
Windows caches writes in memory. So what could happen was that windows was behind, still writing at the end of the file, with the rewind and header writes queued to be written and then the user removed the USB stick. This would cause the file to be incompletely written at the end – and even worse, no headers at all to be written. This is one of the causes for the “GUID mismatch” error. Please note – there’s really nothing a software can do to prevent the premature removal of a USB drive, or disconnect of a network drive!
One of the improvements made in AxCrypt 2.x format is that we never rewind the file, instead the HMAC is written at the end of the file, along with a redundant copy of all the headers written at the start. This significantly reduces the risk of a complete failure to decrypt even a partially written file. Of course, if all data is not written, we can’t decrypt all data because it’s simply not there. But we can decrypt and recover what was written. That’s an improvement.
All this being said, the most common reason for “GUID mismatch” is that users rename non-AxCrypt files to end with “.axx”.
In summary – this is why one should not use deprecated, unsupported, unmaintained software!
Hello Calisson,
AxCrypt works by having one instance of itself always running, that’s how it can stay signed in and keep track of files and events etc.
Some operations, notably those that are initiated from Windows Explorer, cause a secondary instance of itself to be launched. This secondary instance “talks” to the primary instance by connecting locally via TCP/IP (it’s a simple and fairly universal mechanism).
The error message indicates that it comes from a secondary instance trying to “talk” to the primary instance, but failing. AxCrypt uses port 53414 for this.
So, first of all – if you can start AxCrypt and sign in using it’s own window, not via Windows Explorer, that should still work fine. Do this by clicking the Windows or Start button, type “AxCrypt” and launch AxCrypt.
The actual problem is likely to be caused by a firewall blocking the use of TCP/IP, even internally in your computer. Please check any anti-virus software you have (many include a firewall) and the Windows built-in firewall.
Hello Savage,
I am sorry to hear this. This is certainly not the typical user experience! It really does work very well for 100s of thousands of users… We’d love to help you out, if you give us the chance.
Looking a little at our logs, there seems to be some issues on “your” side of things. The title says “freezes screen”, but we can see quite a bit of activity. It doesn’t look intentional, but you start by creating an account – where a one letter of the user name email 5 characters before the ‘@’ is a ‘g’. Then a little later you try again, but create a new accout where the letter in that position is now a ‘d’.
You’re also it seems bouncing a bit back and forth between the app and the web page – while that will work, it may be confusing.
Finally, it looks like you never succeeded in verifying the account – that’s the standard procedure used almost universally by service providers like us where we send an email to the registered email adress with a unique code. This in order to ensure that the person registering really has access to the email inbox and has spelled the email corrrectly.
So, I’d appreciate it if you could tell me if the screen really *freezes* – or you mean that you can’t get past the sign in screen?
You might be helped by seeing how it’s supposed to work here: https://youtu.be/jyixJ03qmkg . Read more at https://forum.axcrypt.net/information/get-started/ .
Hello Bob,
You write: “Thus I have 2 logins and 2 passwords to switch between. All files are encrypted and secure when both are logged out.“.
Yes, that works fine, and is the way it’s supposed to be used – but, what I’m trying to say is that with one single Windows Account on the computer, it is very inconvenient to switch AxCrypt user.
You mention “multiple devices are much less cumbersome and more secure“. That is not what I am suggesting you need.
I am saying that the same physical Windows PC should have (at least) two different Windows accounts on them. A Windows computer is designed to be used by multiple persons. This works by creating different accounts on the computer, preferably on per physical person using the computer.
You’d place the the shared, but encrypted, files on a shared folder in the computer – that’s a folder that everyone on the same computer can access from their respective accounts.
Using different accounts has the added advantage of separating personal files, browsing history, bookmarks in the browser, saved passwords and other sign in sessions etc etc.
One computer – many persons with different accounts.
Hello Bob
Still not with you I’m afraid… I’m really trying, but I don’t follow your thinking. Sorry! Can you try to elaborate?
You’ll find the download for the old v1 at the old http://www.axantum.com site. You need to browse the site to the download page (start by clicking the logo in the top left corner), or you’ll be redirected to the new download page. Sorry for the inconvenience, but there are so many links out there that we really would like to point to the new site.
Hello Bob,
I am sorry it’s not working the way you are used to, but in this case it’s not really about “my conceptions” – it’s about standard, normal security practices. Do not share accounts, on Windows or anywhere else security matters. It’s just that simple! Has nothing to do with differences between version 1 and 2 really.
Anyway, return to version 1 is done by decrypting any files encrypted or re-encrypted by version 2, uninstalling version 1, installing version 1, and then encrypting the files again with version 1.
Not quite sure what “2 unique logins on V2.x” means in this context. Two separate Windows logons, definitely. Two different accounts with AxCrypt, yes – but it’s inconvenient because we don’t support switching between accounts so you’ll have to clear settings between different usages.
July 4, 2018 at 20:59 in reply to: Impossible de récupérer mes fichiers encryptés avec la première version #10862Hello François,
The extension .$#! has never been used by AxCrypt. It has however been used by something called Cryptext : see http://filext.com/file-extension.php?extension=%24%23%21 .
If the files are also green, it means they have been also encrypted with Windows Encrypting File system. You might start here for more information: https://en.wikipedia.org/wiki/Encrypting_File_System .
So, it seems the files are doubly encrypted – and not at all with AxCrypt. Sorry!
Hello Bob,
Even if you share the computer – you should *not* share Windows Accounts! This is just a bad idea in so many ways, especially if you have information that is confidential enough to warrant strong encryption like AxCrypt.
So respective users should log on their own Windows Account. They should do so regardless of AxCrypt 1.x/2.x or any other concern!
Hello Bob,
These are rather common questions. Please check out the following blog entries:
Hello MAREZ,
This is because the file was originally encrypted with a different password than you’re signed in with. Since AxCrypt already tried that password that you’re signed in with, it asks for another password. When you then re-enter the same as you’re already signed with that won’t help.
You need to know what the original password was.
Hello jay,
The message means that AxCrypt is trying to open or decrypt a file that does not contain a predefined fixed sequence of 16 bytes that start off every AxCrypt file.
A possible reason for this is if you’ve associated other extensions than .axx to AxCrypt. Also, while I’m not sure, the message seems to indicate that you’re using AxCrypt 1.x. This is no longer supported or maintained.
Hello Mike,
Happy it worked out for you, good luck!
And thanks for the support in the World Cup. But, hey, most people see it as Sweden vs. Sweden so Sweden wins in any case ;-) .
Hello Mike,
Graham makes some good points. To clarify:
The reason only password reset is enabled is because you’re not signed in.
You need to know the old password, and sign in, to *change* the password. This is the same via the web.
Hello Debbie,
this is because your file is encrypted with a different password than you sign in with. Since you’re signed in with lets say “MySecret999”, but the file is encrypted with a different password decryption fails and AxCrypt asks you for the correct password. You then enter “MySecret999”, but AxCrypt has already tried this since you’re signed in – so it tells you this that it’s no use to re-enter the sign in password. It’s already been tried and it doesn’t work.
You need to remember the password originally used to encrypt the file.
Please be aware that a password *reset* will *not* let you access previously encrypted files, that were encrypted with the password used before the reset. A password *reset* will only let you sign in, and will be used for new encryptions. To decrypt files encrypted with the previous password, you need to know that previous password.
Hello Robert,
I appreciate the feedback, and we do try to adapt as best we can. There are several design decisions involved here, not 100% sure which one(s) are the critical ones here. I do think that disallowing passwords such as ‘password’, ‘secret’, ‘123’ and ‘a’ is an indisputably good design decision.
The other decisions, such as using the sign in metaphor for deciding on what password to use by default for encryption and decryption can of course be discussed, but what you can’t know is that it’s based on actual use of the “old” model. One recurring problem with the old model with the need to re-type your password every time an encryption was to be made and the only verification done was by typing it twice was that users mistyped (twice) and then lost their data.
The sign in metaphor allows us to verify that the password used is actually the same one as was used the first time. This has virtually eliminated the data loss caused in version 1 by mistyped passwords. It has also reduced the number of instances of lost data due to immediately forgotten passwords at first time use.
Finally, the design decision involved here with sharing is not requiring the sharing of actual passwords, is also in my mind a good one. However, here we’re open for allowing password sharing in addition, since we do see some cases where this would be beneficial. We have an issue for this, you can follow it here: https://bitbucket.org/axantum/axcrypt-net/issues/131/add-sharing-password .
-
AuthorPosts
