[SvanteSpectator]

Hey, Dale and Brian and everyone else!

This is your friendly lead developer of AxCrypt and sometimes moderator. We’d like to keep this a nice and helpful part of the Internet.

I think your discussion is definititely helpful and full of valid views and input from all sides, but sometimes frustration over not feeling one or the other getting the point across shows in the language used. I’m stepping in now, not because this thread has derailed, but to keep it from doing so.

Let’s all respect each others opinions, and we can all learn from a discussion like this.

I’ll refrain from adding any comments on the actual issue – I think I’ve expressed them earlier and elsewhere.

Just one thing on this kind of discussion; just because I or the team has expressed an opinion at one time or another, doesn’t mean we can’t change, tweak or even reverse our position on an issue. Which already has happened on this issue, to a large degree because of discussions like this one.

So, keep it coming from all sides, but let’s all stay nice people! We all have a common goal, to protect our information confidentiality and personal integrity in various ways, where AxCrypt is hopefully one piece of the puzzle.

Thanks all to contributing here! We want this to be a community where we all can learn and contribute, and we as the team behind AxCrypt want to keep adapting and improving AxCrypt as result of the discussions here.

[SvanteSpectator]

Hello Doug,

First of all – if you have a backup, you have a backup. If you could open them before, you can open them now (at least by definition with the same version you hade before). AxCrypt 2 does open all AxCrypt 1 files – we do not have an reports to the contrary. If you can’t open them now, you couldn’t opent them before either – simply because you’re not using the right password.

What may confuse you when you revert back to AxCrypt 1 is that files that you have successfully opened with AxCrypt 2 will have been re-encrypted with the AxCrypt 2 updated file format, and with the password used to sign in to AxCrypt 2 (which is not necessarily the same as the password you originally used for AxCrypt 1).

This upgrade of files is probably the reason you’re now getting “the version difference is too large”, although the intention of the old code is actually that you should be getting a message stating “File saved in newer, unsupported, version. Please upgrade.”. However, it’s really hard to be future compatible, so it’s possible the old code flags the newer format as you experience.

I think that if you examine the “modified” date of the files in your backup, and try to open them with your known password using the old version (or the new, I suggest the old just so you can have increased confidence) I think you’ll find that the problematic files occur in date-time clusters. The most probable reason is that you mistyped the password (or used a different one than what you think now) when you encrypted these files. The whole “sign in” system / single password with AxCrypt 2 is designed to minimize the risk of this happening, since we know it does with AxCrypt 1 sometimes.

Rest assured, if you have the original password, you can open the files. Especially the ones from the backup and using the original software, since then we’re removing even the theoretical possibility that the upgrade has anything to do with it.

[SvanteSpectator]

Hi Nathan,

Thanks for the feedback!

I’m thinking that it’s quite a bit about the perception – not the actual situation here. The recipient does need AxCrypt, in all situaitons, it’s just with the “self-decrypting” your perception is that you don’t need AxCrypt – because it’s “self-derypting”. In actual fact it’s still AxCrypt, it’s just a version of AxCrypt that has the data tacked on at the end of itself and reads it from there.

In fact, if you have 10 “self-decrypting” files, you have 10 copies of AxCrypt on your computer. But, yes, I get how it is seen.

We were hoping that users in most cases would see the benefit of the fully-featured portable version instead of the severly stripped down and limited “decrypt only” function of the “self-decrypting” files.

Perhaps we should improve in our communication of how the portable version works, to better explain how it really is a substitute. We’ve also considered making ‘zip-packages’ of encrypted files with the portable AxCrypt included in the archive.

Let’s hope to hear from more users, although this thread is a bit off topic now. I’ll discuss internally to add a another main forum for “Feature Requests”.

[SvanteSpectator]

Hi DragonTear,

Nathan is essentially right in his response (thanks!), although I’d like to point out that using AxCrypt 2 portable does not require installing it, just like having the old-style “self-decrypting” file does not require you installing it.

In fact, the only difference is really that you now need two files instead of one. AxCrypt-2.1.NNNN.exe + Whatever-ext.axx.

Anyway, since this question does keep popping up and while we’re still not planning on implementing it for the reasons mentioned in the blog post referred to by Nathn – we’re still interested to achieve similar benefits for similar situations.

So, if you just please explain just how you use the self-decrypting feature, and just what it is about it that is so attractive, perhaps we can come up with a way to satisify everyone?

[SvanteSpectator]

Hi Clare,

It’s possible that Graham has understood your problem and the response will help you out. If not, please add a screenshot to where you’re stuck or explain further just what the problem is.

[SvanteSpectator]

Hi Dale,

I did say we are perhaps not allergic, but at least very sensitive to options. They tend to mess up the usability. That doesn’t mean we will refuse to add any options at all. Some are necessary, but what we’re saying is that we think twice at least before adding an option.

The auto sign out option is actually on the to do list.

https://bitbucket.org/axantum/axcrypt-net/issues/208/sign-out-automatically-on-a-set-time

[SvanteSpectator]

Hi Frank!

Yes – Missing .NET 4.5 or later will cause a similar (but not the same) error. Also depending on if you have .NET 4 or not…

[SvanteSpectator]

Hello Frank,

Thank you for the information, but while I’m sure you had a problem, this unlikely to be the same issue. AxCrypt 1 (the old version) is entirely written in C++/Win32. AxCrypt 2 (the new version) is written in C#/.NET. The error message is caused by a .NET component having problems. The old version had no components shared with .NET, and installed no system components that could be shared.

In short – it’s really hard to see any way that a problem with AxCrypt 1 – broken or not, could affect AxCrypt 2. However, a broken installation of AxCrypt 2 could certainly cause similar symptoms.

What probably fixed it for you was the reinstall of AxCrypt 2, as probably the original installation was broken for whatever reason.

Installing AxCrypt 2 over AxCrypt 1 is a supported scenario and will normally work just fine.

[SvanteSpectator]

Hi eddie,

If the file was open during the install of the new version, that at least is a special situation. In that case the upgrade in a way could be related, although it’s a very special case. We have not tried stress testing that particular scenario, but what does happen is that the new software will initiate an uninstall of the old, and that uninstall will in turn ask any running processes to end. It’s supposed to do this in a nice and orderly fashion of course, but it’s not impossible that something could go wrong here causing the old AxCrypt to ended prematurely while writing the updated encrypted file.

I do not recognize this situation at all, it’s actually a first that I’ve heard of, so it’s certainly a pretty isolated case. Still, I’m very sorry for the inconvenience. We do try to make the software as reliable as possible in as many situations as possible.

[SvanteSpectator]

Hello Hov,

Please read https://forum.axcrypt.net/support/faq/#lavasoft-crash  . It is most likely the cause of your trouble.

 

• This reply was modified 7 years, 9 months ago by  Svante.

[SvanteSpectator]

Hi eddie,

Sorry to hear that. So, you’re saying the file in question resides on a local fixed hard drive? It’s pretty much unheard of that an AxCrypt file would be damaged like it appears to have been on a fixed drive.

Did something unusual happen in the vicinity of the last update of the file? Perhaps a forced reboot by Windows, a power outage, a crash or anything unexpected that could cause a file not to be completely written to disk by AxCrypt?

[SvanteSpectator]

Hi eddie,

The file was then damaged during the update today. Hopefully you have a backup of the encrypted file?

The problem here was not caused by the update of AxCrypt, since the first thing that happened was that it was not recognized.

This type of damage can happen when a file resides on a removable drive, such as a USB stick, and it is removed without using Windows Safe Removal. Resetting or crashing the system can have the same effect. It has nothing really to do with AxCrypt, it’s how Windows works.

In fact, with AxCrypt 2, we’ve done some things to mitigate this kind of situation so that if it does happen, chances are at least part of the file can be recovered. In the end though – if something happens stopping Windows from actually writing file contents to a drive, that file will be damaged.

[SvanteSpectator]

Hello eddie,

This has nothing to do with the upgrade as such. The file in question is indeed either not an AxCrypt file, or more likely unfortunately, damaged to the point where it is no longer recognizable as an AxCrypt file.

When did you last open the file in question, and more importantly – when did you last modify it?

[SvanteSpectator]

Thank you Hans!

[SvanteSpectator]

Hello Świętomierz,

The root certificate is not the main issue for an attacker here. Although I do not use Kapersky, from your description it’s fairly clear that what it does is install itself as a proxy locally in your computer.

When you connect to for example our server using SSL that proxy can’t see and inspect the encrypted content unless it actually decrypts the traffic. Since it’s configured as the system proxy, what actually happens when you connect to https://forum.axcrypt.net/ is that you are connecting to your proxy. This is where the installed root certificate comes in (this is likely a unique certificate generated locally just for you). The proxy now generates a certificate for “https://forum.axcrypt.net/” and signs it with that root certificate. Since you have previously installed the root certificate as “trusted” in your computer, your browser will now trust the connection.

What the Kapersky software does is essentially a “man in the middle” attack in your own computer.

The connection over the Internet then proceeds as usual, except that it’s Kapersky who will be validating the certificate presented by “https://forum.axcrypt.net/” and establish the encrypted connection over the Internet. If the Kapersky software is implemented as I am guessing above, this means that the Internet connection is just as hard to listen in to as before. It does require quite a lot from Kapersky to do the connection negotiation properly, I would rather trust Microsoft or Apple etc for this (if I have to trust someone, which I do for this).

Mounting an attack against an SSL connection over the Internet is no small thing, even if the server (i.e. http://www.axcrypt.net) certificate is somehow compromised. The attacker needs access to the data stream, and that requires some actions that are really hard to achieve unless you’re a provider or in national security. The provider would normally not be interested, unless its being forced to comply by national security – which is what has happened in a few known cases in the US.

[Author]

Posts