Forum Replies Created
-
AuthorPosts
-
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
May 27, 2016 at 07:31 in reply to: Encrypt files with their own individual passphrases and sharing them #3260Hello,
This is Svante from AxCrypt!
(I’m responding only here, not separately to the two separate requests you sent via the premium help form on the web. Please also remember that we’re on central european time with daylight savings, UTC+2, and we work during normal office hours mostly).
Now, to answer your question (we’ll be making a video on this soon).
With AxCrypt 2, the way to enable others to open shared encrypted files is not via different individual passwords. It’s much easier. We call this key sharing.
What you do is that after encrypting the file, you right-click it in the main AxCrypt window and select “Key Sharing”. In the dialog box, you enter the other parties e-mail addresses, click ‘Share’ and then ‘Ok’. This will share the unique file key actually used for encrypting the file with the designated parties.
Once they receive the file, via e-mail or any other mechanism, they will be able to open it with their own password.
Yes, each person needs to have a copy of AxCrypt, but if they can’t or won’t install AxCrypt on their computers they can download the portable version. These are all available on the download page at http://www.axcrypt.net/download/ .
Svante
Hello,
Ok, well the thing with encryption is that if you don’t know the password, you can’t decrypt. There’s no way to bypass that, that’s what the whole thing is for. That’s what makes encryption different from access control.
You need to remember what password you used when you originally encrypted the file(s).
Svante
Hello Nina,
Glad it’s starting to work. Do not forget to update to the latest version also.
Not sure I understand the following which you write: “I can’t remember the password for my encrypted files :( Is there a way in which I am able to decrypt without needing to retype the password for all of these encrypted files?“.
If you can’t remember your password, that’s a problem. You need to remember it.
The other part about retyping I do not understand, can you explain further what the problem is?
Svante
Hello Paul!
I’m sorry that you seem to have had problems with our new version of AxCrypt. We’ll be happy to help you out, if you’ll give us some more information about what is not working.
Please start a new thread here with an appropriate title describing your specific problem, or use our Premium Help at https://account.axcrypt.net/Home/Support .
Do let us help you out! I understand that AxCrypt 2 is different from the old, but I’m convinced that for most scenarios it is much superior, even if different.
Finally, you’re of course welcome to continue using version 1.7.
Svante
Hello Davide,
Thank you for the feedback!
Generally speaking, the idea is that the AxCrypt-user essentially has a one-to-one mapping to the Windows user. So, if you’re logged on to Windows, you already know what you have encrypted. Also, it’s never supposed to be a secret just what is encrypted.
Given all this, there is one thing that I’ve debated a bit, and that’s that we show the plain text file names in the recent files list. The decision to do so, is based on the above assumption on the relation between the Windows user and the AxCrypt user. In the file system, the plain text file names are actually encrypted using local Windows encryption which is based on the Windows log in credentials.
-
AuthorPosts
