Forum Replies Created
-
AuthorPosts
-
May 30, 2016 at 18:51 in reply to: Encrypt files with their own individual passphrases and sharing them #3289
Charles,
I think you misunderstand. AxCrypt 2 does all that AxCrypt 1 does (and some more). You can still use it exactly like oyu describe for exactly that purpose, even more conveniently than before.
You do not *have* to share documents! If all you need is straight-forward password protection via 128-bit encryption of files (like AxCrypt 1.7), then the Free version of AxCrypt 2 fits the bill perfectly.
Best regards,
Svante
May 30, 2016 at 18:48 in reply to: Can't open existing Axcrypt files with latest version of Axcrypt #3288Robert,
Yes, that’s the gist of it. We’ll be publishing detailed specifications about exactly what we do, both in laymen terms as well as with technical details. We’ll also be publishing documentation about the file format we use, and how we apply the cryptographic primitives, as well as how to call our public REST API (which is what AxCrypt does for it’s online extensions).
For now, though, I’ll try to answer questions such as yours well as I can (and then I’ll re-use some of the text when I publish it more formally).
I feel that we have a reasonable compromise between theoretical security and practical usability. Of course, not all will agree, but we’ll be very upfront with exactly what we do and why.
Good luck!
Svante
Hello Parham,
AxCrypt 2 can operate as Freeware, or as Premium with extended functionality. So it’s both. Often called Freemium. You can always download the old verson 1.7.x, which is entirely free and does not have the extend functions of AxCrypt 2.
The Free mode of AxCrypt 2 is roughly equivalent to AxCrypt 1.
May 30, 2016 at 14:28 in reply to: You should consider a new Premium type version on a regular shareware basis… #3284Thanks Sputnik! Be sure to stay tuned, we’re working very hard on all fronts to make AxCrypt better and more accessible and to please as many users as possible, both with usability but also with licensing of course!
Thanks Davide! Please post again if you have further suggestions, questions or ideas.
Svante
Jodi, I hope it worked out for you. You should be able to get it working with updates – even if XP is decomissioned you should still keep it as updated as possible.
Svante
Hello Peter,
Have you tried the most recent version? We did some changes in the proxyhandling in version 2.1.1394 on May 25.
Svante
Yes, we do! It’s very high on the agenda.
Hello Dana,
Yes, we’re definitively planning on doing this. It’s at the top of our priority after smoothing over some initial usability bumps in AxCrypt 2 for the Windows Desktop.
Svante
May 30, 2016 at 12:00 in reply to: Can't open existing Axcrypt files with latest version of Axcrypt #3278Hello Bernie,
Update to the most recent version of AxCrypt and enable automatic conversion of old AxCrypt 1.x files. This will convert them to the new format and AxCrypt ID sign in password as you go along, and make the use much more convenient.
Regards,
Svante
May 30, 2016 at 11:58 in reply to: Can't open existing Axcrypt files with latest version of Axcrypt #3277Hello Robert!
No, it’s not a stupid question… But the answer is important. So where we go.
In the good old days (and scarily enough even today in way too many cases), log in to sites was done by storing your password as you type it, typically in a column in a database or a in key-value text file.
Then as it was realized this was a bad idea, a hash of the password was stored instead. This is still the most common form. The idea is that it’s computationally impossible to reverse a hash, so you can verify a password, but not figure out what it is from the data stored on the server.
Then, as computers got faster and memory larger, people figured out they could precompute huge tables with potential passwords and hashes, and then do a quick reverse look-up. This was about 40 years ago, in the early 1970’s and the good people at AT&T developing Unix incorporated the idea of a salt, a non-secret random quantity added to the hasing process along with the password, making pre-computing more or less infeasible. What’s really scary is that this basic technique is over 40 years old, and still probably over half of the systems today including newly developed (for example Linked In up until 2012) still don’t use this elementary technique!
All of the above store the password or a direct computation from the password on the server.
What AxCrypt does is subtly different. Here’s the thing: What is AxCrypt made for? It’s made so that if an attacker gains access to an encrypted file, the only recourse is brute force (trying each and every possible password) and that is actively made more difficult by an iterative process.
What we *do* store on the server, are one (possibly a few) encrypted files, one AxCrypt-encrypted file and one XML-encrypted file (for historical reasons, we’ll migrate to AxCrypt for that as well). These encrypted files contain the secret part of a RSA key-pair, which is the technique we use to implement key sharing (sharing of encrypted files among users, who use their own passwords) and optionally passwords stored using the password manager.
So, while we do not store your password on the server, we do store data encrypted with your password. In one sense this is similar to storing password hashes, but in another important aspect it is very different.
Our assumption when describing the security model of AxCrypt is that an attacker has access to your files, our specifications and our code. I.e. – nothing is secret except the password.
Thus, assuming an attacker would gain access to the server and export a file encrypted with your password, nothing has changed. We already assume that an attacker has that access, since that’s what AxCrypt is made for – to protect your files if they are exposed.
Now, there is one twist to this. We do send the password to the server and let the server decrypt the file if necessary. This is not strictly speaking necessary, we could pass the encrypted data to the client and do all cryptographic stuff on the client. However, our thought is that we gain a lot of usability and flexibility for the users by doing it this way, at a very low expense security-wise. Our users already entrust us with their data via our code on their clients (where we have little control over the environment), so we think it’s a reasonable compromise to allow our servers (where we have very strict control over the environment) the same access. The ‘weak’ link in this case is the transport over SSL. Here’s the thing with AxCrypt and me – we’re not conspiracy theorists. We actually believe SSL works, and Snowden appears to agree with us. Strong encryption works. That’s why the agencies have had to cheat so much!
Right now we’ve made the call to prioritize usability over a formal zero-knowledge model. I’m not really a big fan of the zero-model knowledge model when applied to situations like this, since it essentially assumes the user is absolutely trustworthy, which (s)he is not! It’s theoretical model, that works differently in practice.
This decision may change in the future, we’ve not built anything that absolutely requires the password to be made available to the server at all, but right now, yes it is during the sign in process and when working online via the website or the REST API. But we don’t store the password or a hash. We do store one or more encrypted files.
Hello Rollmops,
You only need to go online the very, very first time you use AxCrypt 2 on a PC. Thereafter there’s no such requirement.
The Premium price is not at all just for 256-bit encryption, it’s for much more! Including support, key sharing (work with encrypted documents with others), a password manager, secured folders and soon also mobile apps will be included in Premium. See http://www.axcrypt.net/pricing/ for the feature comparison.
Indeed there are free programs offering multiple encryption algorithms, but that’s part of the thing with AxCrypt. We make those choices for you, and in just about every case we do it better or as good as the user thus not annoying the user with a choice of algorithms.
Actually, if you like, you can plugin different algorithms to AxCrypt 2 if you’re C# savvy.
Bill,
I’m sorry you did not like version 2, but you might want to persist a bit. It really does have it’s advantages, even if it’s different! But if you insist of course you can get the previous version. Just go to http://www.axantum.com/AxCrypt/Downloads.aspx and download version 1.7.x (3156 is the current build).
May 30, 2016 at 02:15 in reply to: How to stop sign-on screen every time system wakes from sleep #3271Hello Laurel!
Well, I guess it’s hard to please everybody. This was put in due to frequent user demand.
I really don’t like options and settings, but I don’t want to make annoying software either! It’s not a hard thing to fix, but it would be nice if it could be done implicitly somehow.
One idea is perhaps to *not* sign out if the screen saver or sleep mode *is* protected by a password. Do you have to enter a password to get into Windows after your PC wakes from sleep?
Svante
May 29, 2016 at 23:27 in reply to: AxCrypt Version 2 Not Putting Changed Documents Back to Original Folder #3270Hello Laurel,
Thank you for your feedback. Glad you figured it out, but as you noticed this can be confusing and AxCrypt can do better.
We filed an improvement issue on this some time ago, it’s on the short list to be implemented soon. See https://bitbucket.org/axantum/axcrypt-net/issues/92/encrypt-extra-files-in-the-work-folder .
Svante
-
AuthorPosts