[AxCrypt SupportModerator]

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?

[AxCrypt SupportModerator]

Hello Hjalmar,

Aha! I see ;-) That kind of fingerprint!

Well… The idea behind the AxCrypt PKI is that you trust the AxCrypt server (yes, I know, but we’re willing to make well-defined compromises to achieve a higher level of usability). So, if you know the recipients e-mail address and know that the entity behind this email is who you want to communicate with, that should suffice.

Maybe I’m still not understanding? I will admit I respond perhaps a little more rapidly than your quite advanced suggestions require…

[AxCrypt SupportModerator]

Thanks Hjalmar,

Handling the key pair and licensing can absolutely be done with a zero-knowledge protocol, like yours or similar to it. Actually I think it can be made even more simple, by simply generating the key pair locally and only upload the encrypted private key, never generating or encrypting it on the server.

The main problem you have already pointed this out – the online password manager. It gets so much more complicated and risky if the data is kept locally, and it completely (well, almost) removes the use of it with a simple web browser – which actually is a very important use case for it! Downloading and uploading updates is of course possible, but inefficient after some time, and a little risky.

Another problem, but it can be handled, is the invitation process. Where Alice invites Bob to a document, and Bob does not have an account. What we do now, is we generate the key on the server, and keep it encrypted with a machine key utnil Bob sets his own password, at which point the key is re-encrypted with that password. Of course, that can be tweaked to only use it as a temporary key until Bob sets his password at which point we update the key pair on the server with a locally generated one. This would minimize the exposure, even if not remove it completely.

Of course – if you don’t use the password manager or ever sign in on the web, we don’t need to see the password.

However, it does get a little more complicated for users to understand what’s going on, and for us to support them.

We have relatively few users actually requiring zero-knowledge at this time.

Concerning fingerprint support etc, it requires a little bit of extra consideration. Please read my blog post on the subject for a longer discussion: https://forum.axcrypt.net/blog/encryption-and-biometrics/ .

Further comments welcome. We will be developing along these lines, but we some other priorities currently – most notably Mac OS X support which is coming soon!

[AxCrypt SupportModerator]

Hello Carl,

I’m not following. The Google Authenticator is still about proving identity – not possessing a secret. Remember that AxCrypt is designed to handle the following scenario:

The attacker has access to the following:

– One or more encrypted files, and the original decrypted originals for all but the file(s) being attacked.
– All the source code and technical documentation for the application.
– Tools and skill to use, write and adapt code to try passwords/keys without interference of operating system or server authentication – i.e. entirely offline and under the attackers control.
– Lots and lots of hardware (think custom built supercomputers) and money, vast amounts of money (many, many millions of $).

In fact, the only things the attacker is not assumed to have is the password, and you (so you can’t be forced to reveal the password).

Therefore, having various additional stronger “authentication” methods does not really make sense, since we assume the attacker can get round those. We still want AxCrypt to stand strong. And it does, provided you use a sufficiently strong password, which we try relatively hard to help you with.

[AxCrypt SupportModerator]

Hello Mike,

Not quite, quite yet…. We just started the internal beta this week. We’re planning going public with the beta within a week or two.

[AxCrypt SupportModerator]

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.

[AxCrypt SupportModerator]

Hello Anonymous,

Please upgrade AxCrypt, that’s a really old version, and try again. You’ll find the latest at https://forum.axcrypt.net/ .

[AxCrypt SupportModerator]

Hello Anonymous,

If you please can provide more information about your problem, and if you can send a screenshot explaining where the problem is it is the best.

How to take a screenshot is explained here: https://support.microsoft.com/en-us/help/13776/windows-use-snipping-tool-to-capture-screenshots .

[AxCrypt SupportModerator]

Hello Dean

If you please can provide more information about your problem, and if you can send a screenshot explaining where the problem is it is the best.

How to take a screenshot is explained here: https://support.microsoft.com/en-us/help/13776/windows-use-snipping-tool-to-capture-screenshots .

[AxCrypt SupportModerator]

Hello Hjalmar,

Thanks again for your input. Yes, the SSL/TLS issue is frequently debated and many distrust it for the reasons you describe, and with reference to various conspiracy theories.

I like your idea of using AxCrypt to encrypt the password as it is sent to the server, we’re actively trying to make the analysis as simple as possible, and that entails using / relying on as few mechanisms as possible. We’ve already discussed various ways of strengthening the protocol, including making a zero knowledge variant. (The problem with that is that some other things become less convenient. But that’s a longer discussion.)

The problem that will have to be investigated is just how robust such a large HTTP header is in practice. For it to be a relatively “simple” fit, I’d like to continue using basic authentication, and this entails sending the password in a HTTP header. A minimum AxCrypt file right now weighs in at about 5K, this can probably be reduced a little by extending AxCrypt to support a file-less format (that’s useful for other situations as well, such as AxCrypt-encrypting pure text etc), thus reducing the amount of headers etc, and perhaps even skipping the redundant headers in the trailer. But then it has to be Base-64 encoded, so it grows again. In the end the header will probably be on the order of 4K. To be honest, I just don’t know how will this will work. A mitigating factor is that it’s still inside a SSL/TLS connection so it should not be affected by intermediate stuff.

Still, I like it. Even better, it can be added without any problem for existing clients. The server can easily distinguish between the cases.

See:

https://bitbucket.org/axantum/axcrypt-net/issues/276/filter-out-components-from-the-user-email

https://bitbucket.org/axantum/axcrypt-net/issues/277/implement-file-less-axcrypt-encryption

https://bitbucket.org/axantum/axcrypt-net/issues/278/investigate-and-possibly-implement-axcrypt

Thanks!

[AxCrypt SupportModerator]

Hello Hjalmar,

What can I say? Thanks! Lots of very good and relevant thoughts and notes. Some are on our issue list, some will soon be ;-)

One thing surprised me – you say there’s lots of dead and unused code? Could you point me in the general direction, I try very hard to get rid of dead code as soon as it’s dead. One thing you may not be aware of is that while the Windows desktop and the core libraries are open source, we also use the core libraries in our mobile apps, our soon to be released Mac app as well as on the server side ( https://account.axcrypt.net/ ). So, if the methods are public, they may be used by other code that is not part of the axcrypt-net repository.

The plan is to separate the core libraries into a published SDK nuget package once the most intense development phase is over. But for now, when we have no less than 5 platforms rapidly moving forward using the core libraries, it’s just so much more convenient to include it as a source dependency.

Also, about the ease of cheating with the Premium status, it’s a known situation and conscious decision although we will do a few minor changes in the near future where it at least requires you to hack the source. It’s hard to make strong DRM with open source like this. In the end there will always be a place in the code where the policy is applied, and where someone can hack it away. With or without the source, but it’s of course so much easier with the source. We could obfuscate and do sneaky things, but it just doesn’t make sense for us. If someone really wants to hack the source to get at the Premium features – so be it. There’s still quite a bit of things that are outside of this, which includes the mobile apps and the server-based features (of course if you want to be always offline, none of that makes much sense to use anyway). I could even consider making Premium the default in always offline mode!

As for always offline causing an OfflineApiException I seem to recall that’s just how it’s implemented. Normally, if a connection to the server fails, we throw an OfflineApiException. If we’re always offline, we do the same but before even trying, causing the rest of the code to see no difference between “unplugged”, “server down” and “always offline”.

In any case, the level of your comments indicates I’d like to talk to you. Please PM me via support att axcrypt dott net if you will. I gather you and your employer values privacy to a great degree, and I’ll be happy to respect that of course.

[AxCrypt SupportModerator]

Hjalmar,

If you want to be really sure – download the source and compile it locally, then you can inspect every line of code to ensure it does exactly what it should.

[AxCrypt SupportModerator]

Hjalmar,

If you want to be really sure – download the source and compile it locally, then you can inspect every line of code to ensure it does exactly what it should.

[AxCrypt SupportModerator]

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.

[AxCrypt SupportModerator]

Hello Hjalmar,

The signature and the hash is correct. We’ve now updated the list of hashes to include the new version as well. Sorry about that.

The portable version stores temporary and configuration files in %localappdata%\AxCrypt but that’s all. If you run in it in ‘always offline’ it will always be offline.

It does not ever need Internet if you run in it ‘always offline’, and does not store anything in the registry.

[Author]

Posts