Unhappy with version 2

[SvanteSpectator]

Hello Captain Quirk, FormerAxCrypter, Wellington, Gerard, Robert M and everyone else!

Wow – I’m impressed at the high level of both questions and responses from the community. The AxCrypt community is amazing! Stuff like this, that makes it worthwhile…

For what it’s worth, while I cannot disclose the names or publish the reports, AxCrypt has been professionally audited by both private and government entities. I realize the value of that statement is pretty low, considering I can’t name anyone, but still. Better than nothing, right?

As for myself, I don’t consider myself a cryptographer per se. I do not, and never have, made my living as a cryptographer. That being said, I have made my living for many years, working with properly implementing cryptography both as a developer and at a higher level with cryptography-based products. As such, I feel that I am uniquely qualified to *implement* cryptography and design software based on cryptographic functions as a developer, which unfortunately too often is not the case. As we have seen time after time in both small products as well as enterprise products from major software manufacturers.

I would like note that while AxCrypt is not as wide spread as for example WinZip, it’s still pretty well known and used. It’s been downloaded an estimated 20 million times, and it’s been open source all that time with published specifications of the technology. During this time, not one single cryptography related weakness or vulnerability has been published. That doesn’t mean there aren’t any, but it does increase my confidence in that it’s pretty sound anyway.

I guess this as good place and time as any to point to the appropriate resources should anyone wish to take a look:

https://bitbucket.org/axantum/axcrypt-net/ – The source code for AxCrypt 2 in C#. A few nuget dependencies, otherwise it compiles cleanly as-is with Visual Studio Community.

https://forum.axcrypt.net/documentation/technical/ – Technical information about file format, algorithms, implementation details and server interaction.

Thanks everyone, and keep it up!

[Dwight]

I have used Axcrypt for years and like many things about the version 1. I like some of the things about V2 but do not like the single password. I have been in tech for 40+ years and dont want to debate the pros and cons of single vs multiple passwords, local vs cloud etc. What I want to do is to revert to V1.7.2867.0 without losing access to the dozens of encrypted files on my system. I am hopeful that the solution does not entail me manually unencrypting each and every file, uninstalling V2, rebooting, and reinstalling V1.

Please advise how to easily revert from V2 to V1.

Thank you,

Dwight

[SvanteSpectator]

Hello Dwight,

Thanks for your input!

Files encrypted with v2 are not possible to open with v1. Files opened with v2 with the auto-convert option enabled (default) will be in v2 format. However, the easiest way if you insist on reverting to the unsupported v1, is to uninstall v2, install v1 and then download the standalone v2 which will enable you to decrypt v2-encrypted files as you need to in order to re-encrypt them with v1.

I’ve been a developer for almost 40 years, and I love to debate the pros and cons of all things, because things change! AxCrypt did not evolve at all for 15+ years. The world did though, and now it’s way past time to get things up to date again, which includes new views on passwords and local vs. remote storage (aka cloud).

Here’s my input to the single vs. multiple password debate: http://www.axcrypt.net/blog/use-of-different-passwords/ .

 

[Dwight]

Thanks for your reply. I have ~300 axcrypt encrypted files on my computer; some personal, others for clients. They are scattered across many folders; several different passwords. Your directions above say that I must touch each file with the standalone v2. That is a lot of work. An automated v2>v1 solution would be much appreciated. Decrypting all the v2 files would result in no files being designated as .axx  . But then it would be very difficult to find the files that were .axx to convert then to v1 or another encrypter.

I am not happy.

Dwight

[Wayne]

“Your directions above say that I must touch each file with the standalone v2. That is a lot of work. An automated v2>v1 solution would be much appreciated.”

It would be nice for an automated solution. I didn’t have 300 files when I upgraded but I know it’s the case that you have to “touch” [open] the file so that it may be converted and you need to have Auto Convert enabled in the File – Options menu otherwise they’ll stay at v1.

Here’s an idea for you. I have no clue how fast your computer is but why don’t you try this:

• open Windows explorer (Win + E)
• run a search for all files with an .AXX extension (*.axx)
• select them all (Ctrl + A)
• press enter

That’ll force them to all load simultaneously and start converting in the background. You might want to keep your AxCrypt 1 password in the clipboard so that you can paste it (Ctrl + V) in the event AxCrypt 2 prompts you for it more than once (assuming you’re not using different passwords).

[SvanteSpectator]

Hello Dwight,

I’m sorry you’re unhappy, but the simple fact is that writing new code in order to convert files back from version 2 in order to use an unsupported version 1 software, is simply not a a priority ;-) We’d much rather put the effort in making you happy with version 2, which we already feel is a huge improvement – but it can of course get better!

However, we do publish all the source code, so you could roll your own if you think the community would appreciate it.

Also, from what you’ve described, I don’t think you’ve actually converted all your 300 files to v2, have you? My suggestion was to have the portable version on hand, whenever you need it. v1 will tell you if the file is too new to open, i.e. a v2 file.

Wayne, for the other way around – converting from v1 to v2, we have that in the program. You don’t have to open each file in order to auto-convert.

[kz]

Hi. Was wondering if you have considered making AxCrypt 2 an one-off purchase

[Captain Quirk]

@ kz: I think I can answer this one for you:

The answer is an emphatic NO.   https://forum.axcrypt.net/blog/subscription-vs-license/

Not that I agree with the reasoning found at the above blog page.  Yes, of course a continuous income stream is great for the company receiving the income.   (Who doesn’t like a continuous stream of income in perpetuity?)  But individuals don’t like the idea of being “roped in” to an endless monthly expense.

The argument in favor of the subscription model is that traditional software gets upgraded from time to time, and therefore you have to keep buying the latest version, so therefore you’re not really saving anything under the “one-time” license purchase model.  But you DON’T have to keep buying the latest version every time a new version comes out.  That’s a fallacy.   Just because a new version of something comes out, doesn’t mean the old version suddenly stops working.

 

Another argument is that since AxCrypt V2 uses server resources that represent an ongoing expense to the company, it’s only fair that the user pay for that functionality on an ongoing basis.  But AxCrypt CHOSE to design their new version that way — the  users didn’t.  I would have been perfectly happy (if not happier) with an application that DIDN’T require the sending of data to and from Axcrypt’s servers.

Just my humble opinion.   :-)

— “Captain Quirk”

[SvanteSpectator]

Hello kz and Captain Quirk,

I wouldn’t be quite so empathic, but I wish it was so simple…

I’m not going to make really long post about this, although I could. But there are many issues that need to be thought out, and then implemented in code and described in text. This means we need to spend time on it. This means we need to spend money on it.

– You don’t really want a one-off purchase. If we fix a bug, that’s important to you the month after, you want a free upgrade. How long should free upgrades be included? After this time, how should the upgrade offer look like? If we implement a new feature, you might also want to upgrade. Should we separate bug-fix-releases and so-called feature-releases? You know the major / minor update “scam” many software companies with the license model use… “We need more revenue, let’s increase the major version digit and make people pay again…” – Parallels is a good example of this. They also make it mandatory by tying the software to a given version of Mac OS X, so if you upgrade the OS, you must update Parallels.

– You may not want our server features, but you do want us to maintain the application. Should we offer an optional maintenance subscription?

– Should we have a trial mode? Should we discontinue the free version, and just have one-off or subscription? Should we discontinue the subscription model entirely? How do we handle all the current subscriptions when they expire? Do we need to refund those that have subscribed for years, or just offer a free transfer to a perpetual license? Should they just be left out and have to purchase a one-off?

– How should the license be delivered, and using what technology? How hard do we need to make it thwart cheaters? Remember, it’s an open source product… Can we depend on the Internet for license delivery? If not, how do we implement license entry in an air gapped situation?

– Sometimes it does not work as you want or think it should. Should free support be included in the one-off? Should we offer an optional support plan?

– If you change your mind, and want a subscription instead, because you find we actually have something you want. How should that upgrade / transfer look like? The reverse is of course also possible, you want to stop subscribing but purchase the one-off. How should that offer and transfer look like?

– Should the one-off be valid for all your devices? One, two? For the mobile apps? If not, they too need to implement all this. The soon to come Mac version? Should we have bundles?

– How do we explain all of the above to you and the other users? How do we provide information so you can make an informed decision about going with the Free, with the Premium subscription, or with the purchased License? What languages do we need to support this information in? Every text change in the software currently triggers about 10 translations, every text change on the content web about 2-3 translations.

All of the above, once decided, actually leads to a number of non-trivial development tasks that need programmer time to be allocated, change and addition to documentation and lots of updates and additions to the content web site. Time and money that would then be spent on this rather than making the application more stable and even greater with more awesome features, capabilities, and platform support.

I wish it was as simple as just saying:

“Yeah, let’s offer a one-off price without server access @ €40. Done. Now everyone is happy.”

But it’s not.

Now we have a fairly simple model: We offer a very useful and complete utility at the one-off price of zero. We also have a simple, easy to understand and predictable subscription at the approximate half cost of what comparable commercial alternatives cost with the license model (and these competitors also charge for updates at various points in time etc).

Believe it or not – this is the short post on this question. In reality it’s much more complicated.

All this being said, if we do get time/resources available and figure out a way to answer all of the above and more with good and well-defined answers, we may indeed offer something in the future.

[SvanteSpectator]

Hi kz and Captain Quirk,

Just a real-world example of why I really think our straight Premium subscription is more honest and fair. The following just arrived in my e-mail box. It’s 100% real, but since I don’t want to throw dirt around, I’ve redacted the actual software name:

Thank you for using the [redacted] by [redacted]!

It’s been a while since you purchased this plugin, and your license key will expire on May 10, 2017. Don’t worry, if you’re currently using the plugin on your website, it won’t stop working when the license key expires, and it’s perfectly fine to keep using it as long as you want!

However, if you’d like to continue to be eligible to receive updates and support for the plugin, you’ll need to renew your license key, and we’d like to offer you a discount of 25% off* the regular price! To renew now, please visit [redacted] and follow the instructions shown.

So, we bought a “one off” license a year ago. Now, we can no longer update it – regardless of security issues, incompatibility issues or whatever. But we can get a new license key for another year at 75% of the original “one off” cost.

I like our subscription better. The reason why a subscription *feels* worse, is because it’s honest! It tells you upfront, in no uncertain terms, that if you want to actively continue using the software with all the bells and whistles, here’s what the yearly cost is. Our subscription is also just for certain features. You have free upgrades forever even if you don’t purchase Premium, so while we’re alive, we’ll keep updating it for new versions of the platforms and fix bugs and any security issues.

Would you rather be hoodwinked like with the above, or have it out plain to see from day one?

[kz]

Hi Svante,

You did make some great points and I agree with most of them. Just purchased a yearly subscription.

So far, it has been a great experience using your software. However, I have some concerns about the current implementation of cloud file encryption.

Currently, files in cloud sync folders that are decrypted are done in-place, which gives the sync software enough time to upload the un-encrypted file. The way I avoid that is to either manually exit the sync software everytime I want to work on an encrypted file (which can be easily forgotten) or move the files out of a sync folder, work on them and move them back. To me, the fact that you advertise ‘cloud storage awareness’, should mean un-encrypted files never touch cloud storage servers (and if anyone didn’t know any better, would assume that as well). That’s the whole point of encrypting cloud files.

Are there any plans to improve this current implementation (maybe like how Boxcryptor or Cryptomator does it)?

Thanks

kz

[SvanteSpectator]

Hello kz!

Thank you ;-)

You make a very valid point about the sync folder issue with cloud storage providers. I’m not sure how Boxcryptor et. al. handles this case, but I believe they integrate very differently and more tightly with the host operating system, working as file system filters and similar. We integrate very loosely, which gives us many other advantages, but this can be an issue if you *really* don’t want any plaintext to hit the cloud ever.

I should mention though that it’s not quite like you say. The problem is not opening and working with encrypted files in a cloud service sync folder. The problem is when you drop new unencrypted files in such a folder, until you tell AxCrypt to encrypt them. Working on encrypted files is not a problem (as long as you don’t actually use AxCrypt | Decrypt). Working with files through double-click is safe in this scenario too.

We can probably never, with the current level of operating system integration, guarantee that no files ever hit the cloud since it essentially means we have to interfere quite harshly with the cloud service sync software. It must either never see the real file system, or we must be able to tell it to stop syncing or forbid it to sync files as they appear while they are unencrypted.

We’re certainly aiming at improving this, and many other things!

[kz]

Hello, thank you for the response

Yes, that is correct. The problem isn’t when I open axx files by double click or using enter. The problem is when I need to work with a bunch of files (for eg. portable programs with several sensitive setting files and cache), so using double click isn’t an option. Don’t get me wrong, individual file encryption is excellent for portability and documents, though.

I used to use a (cloud focused) program few years ago which got around this by having 2 folders. One that is stored locally and all files in that are stored un-encrypted. The second folder is an encrypted mirror of the first one and can be placed anywhere (in this case, a cloud sync folder); and any changes in the first will updated on-the-fly on the second one and that way, no un-encrypted data ever touches the sync folder. However, this solution isn’t ideal for people who don’t want ANY plaintext versions of their files on their hard drive.

Boxcryptor fixed that by instead using a virtual drive (open-source dokan/dokany library) with all the first folders that only ‘appears’ plaintext to the system (kind of like a mounted truecrypt/veracrypt volume), hence that solution was perfect for portable apps and no un-encrypted version of files needed to be stored locally or in cloud.

Neither required tinkering with any system files or sync softwares

[Dwight]

I really like AxCrypt and have used it for years. I prefer the V1 approach which allows for different local passwords. I do see some benefit of the single-password cloud approach, but it is not for me; I want my different client files to have unique passwords.

I was able to uninstall V2, reinstall V1, and then use the V2-standalone to unencrypt any files which I opened while V2 was installed. No reboot was necessary. Luckily there weren’t many of them so my 300-ish untouched V1 files were fine; I did touch each one to verify!

So, I will use V1 until V3 comes out with the features I prefer, or move to another solution.

Thanks Svante for creating a good and useful app!

Dwight

[SvanteSpectator]

Hello kz,

Re “dokan”, well actually it does require tinkering with system files, very much so. It’s a kernel mode driver implementing a user mode file system on Windows. That’s what I mean with tight integration with Windows. While it does offer many advantages, we don’t want to go down that road for a number of other reasons. For example, it’s not possible to make a non-privileged portable desktop app since it requires installation of a kernel mode driver. This means it can’t be run or installed on a computer without permanently modifying the operating system and it requires administrative permissions. AxCrypt can run as a pure portable standalone without installing anything. Also, although it’s fairly mature, it’s scary to install a kernel mode driver and be responsible for that and there’s also a big risk with incompatibility with future versions of Windows. It requires something entirely different to work on the Mac and/or Linux, so maintenance and development costs goes up. These are just some of the reasons why we’ve decided to not do it like that.

A more likely scenario for us is indeed to implement a folder mirror, where we work as normal, and just copy / delete files between them as they appear and disappear – but only encrypted files to the secure folder, not plaintext files. There are some UX challenges with that, but we’ll see.

Thanks for the input!

[Author]

Posts