New version feedback

[Jimb]

I recently installed a fresh copy of Windows and figured I’d try the latest AxCrypt.  I’ve decided to go back to a previous version and figured I’d leave my feedback.  Things I didn’t like:

#1 It is very, very unclear what is going on now.  I had to read pages of discussions on these forums before I (maybe?) understood with what password my files were being encrypted.  Old version is clear – I choose Encrypt, I type in a password, done, simple.  New version never asked me for a password when encrypting a file for the first time, which scared me, though I now (think I) understand that it’s just always using the one password that I signed in to my AxCrypt ID with.  This all made me feel very uncomfortable as opposed to it being clear what exactly was going on before.  Since I always access the same encrypted files on multiple computers (via DropBox), it’s also still somewhat unclear to me what exactly happens and what passwords are required when I open a file on one computer or change my password on one computer.

#2 Speed – previously I click on my shortcut to open an encrypted file, AxCrypt immediately pops up before my hand is back on my keyboard, I type in my password and hit enter, and the file is immediately opened.  Now it’s about 3 seconds between clicking and the Sign In dialog popping up (sometimes behind other windows, I think), and then about 7 seconds from when I type in my password, hit enter, before the unencrypted file opens, which is totally unacceptable.  There is some chance this is related to my OS change, I’ll follow up if the old version is also slow when I downgrade ;)

#3 Password retention – I don’t like having to close AxCrypt to get my password out of memory.  As it stands, unless I close AxCrypt, a malicious program could simply attach to the running AxCrypt.exe and grab my password from memory, and an OS crash writes my password in plaintext into the memory.dmp file.  I want to have to type a password, which is nearly immediately dumped from memory, every time I open my encrypted file.

#4 (minor, not enough to influence me) Can’t encrypt files with a different password – seems everything is set to one password.  I suspect your key sharing stuff would satisfy most similar use cases (shared file which you want others to be able to decrypt), but I’m never going to tell someone “sign up for this account to open this file” whereas “run this program” is (arguably) more acceptable.

Things I liked:

I like being able to “clean up”, as with the old version I often get “this file is already open”, despite having “closed” the file (but my editor of choice, Sublime Text, is still open, so AxCrypt, of course, has no way to know).

 

 

[SvanteSpectator]

Hello Jimb,

Thanks for the feedback!

Let me just comment:

#1 – what password is used where. This is a usability issue we’re having only with users of the previous version, and especially those who use several different passwords for whatever reason.

The idea is to make it even simpler – that it’s only one password. For all files. And if you change it, the new password works – even for files encrypted before the change.

The problem you’re having happens when the paradigm of the old and new gets mixed up.

#2 – Speed – it shouldn’t be like you describe. There may be a 1-2 second time after entering the password the first time, thereafter speed should really be comparable. We’ll have to look into that, if you can provide more information.

#3 – Stay signed in – that’s a bit related to #1, it’s mostly existing users why collide with this feature. We made it so, because of various problems with version 1, and to encourage the use of long and strong passwords – which is hard if you have to type them all the time. Nevertheless, we’re backing down on this one and will be adding options to control how this works.

#4 – Different passwords, vs Key Sharing. We really think Key Sharing is the way to go. You do not need to share any passwords, and if you share with someone who does not have AxCrypt we’ll invite him/her automatically as part of the process. Still, we’re considering to add Password-based Key Sharing as a complement.

We’re working on ways to make the transition for existing users more clear.

Thanks again for the feedback!

[Jimb]

And if you change it, the new password works – even for files encrypted before the change.

This confuses/scares me, as this seems to mean to me that either a) you’re keeping all of my old passwords somewhere or b) all files need to be re-encrypted when you change a password (I’ve got some ~1TB backup files encrypted on a network drive that I would not want to wait for a re-encrypt to change my account password…), or c) the password is just unlocking some other key that actually unlocks my files (scary because if that’s the case, I do not know what/where this actual key is stored) or d) I’ll sometimes need to type in one of my old passwords to open a file.

I’m assuming, from what I read elsewhere in the forums, it’s actually D?  If I encrypted the file on computer A and then changed the password on computer B, there’s no possible way for it to know/change/touch the file back on computer A…

 

For speed, I have been exiting AxCrypt when I’m done with it, so that’s probably where the first 1-2 seconds comes in, no idea why there’s the long delay after entering a password and the file opening.  Went back to AxCrypt 1.x and it’s instant again.

 

[SvanteSpectator]

Hi Jimb,

c) is the closest to the actual situation, but there’s more to it.

First, when you sign up for AxCrypt, you get what we call your AxCrypt ID. Technically, this is a RSA-4096 key pair. A key pair consist of two encryption keys – a public key and a private key. The public key is non-secret, and can only be used to encrypt data. The private key is secret, and can only be used to decrypt data.

On our server, we store your AxCrypt ID – the public key in plain text and is available for anyone with an account to get, and the private key encrypted with your password as an AxCrypt-file.

To encrypt a file, the following (simplified) happens:

1 – A random 128 or 256-bit key is generated. We call this the master file encryption key, or session key.

2 – The file is encrypted using AES-128 or AES-256 with the master key.

3 – The master key is encrypted with your password and added to the encrypted file.

4 – The master key is encrypted with the public key of your AxCrypt ID.

5 – Optionally, the master key is encrypted with  the public key of any other recipients that are configured using the key sharing feature.

So, to decrypt a file, you need access to either the original password used *or* the private key corresponding to any public key used to encrypt the master key – i.e. the private key part of your AxCrypt ID.

When you change the password of your AxCrypt sign in, what really happens is that the private key is decrypted with the old password, and then re-encrypted with the new password.

Therefore, as long as you have access to your AxCrypt ID, you can open any file encrypted with it, using the new password. So, yes, there is a way for us to change how you open files on computer A, even if you changed the password on computer B (as long as computer A is allowed to sign in to our server at least once).

As a safety measure, we also as mentioned always also encrypt the master key with the password itself, this protects you from the scenario that you for whatever reason lose access to your AxCrypt ID.

All of the above is a simplified version, the details are more complex, but it’s all done using well-known standard cryptographic techniques and methods. For full details, please check out https://forum.axcrypt.net/documentation/technical/ .

[Jimb]

Ah, okay, thanks for the info.  I skimmed though the technical documentation, and cannot find where the master key is stored – obviously it is at least stored on your server, but is it also locally accessible (in the event of being offline, your servers are down, or your company goes out of business)?

So, changing the AxCrypt ID password does not actually change any files – if someone compromised my system, grabbed my master key, even if I changed my password, they could still decrypt any files.  That makes me a little uncomfortable, although if someone compromised my system to that degree I am already pretty screwed ;).

[Robin]

I understand the master key to be stored on the AxCrypt servers but it’s encrypted with your password. Obviously this means that your password is sent to the servers each time so you have to trust that AxCrypt aren’t retaining it and you also have to trust SSL integrity.

You can certainly backup the key pair using AxCrypt in case they go out of business or the servers go down.

Regarding your hypothetically compromised system… this troubles me too although it could be argued that if this happened then the attacker has access anyway no matter what encryption you use.

Obviously the old version of AxCrypt (1.7) works asymmetrically: enter a password and it’s done but regrettably it’s no longer supported or developed. I preferred the old model and, having scoured these forums myself, the best suggested alternative which is still developed, open source and free is BCArchive. It does all the same as the AxCrypt 1.7 but also has the option for symmetric encryption as well (like implemented in Axcrypt 2). It might be something you want to consider if you don’t like the new AxCrypt trust model (download here).

[SvanteSpectator]

Hello Jimb and Robin,

Point of clarification – AxCrypt 1 is a pure symmetrical crypto system. AxCrypt 2 is extended with some asymmetrical functionality.

We store the private asymmetrical key on our servers, and on your local PC. It’s encrypted with your current passhrase. If your current passphrase is compromised *and* the attacker has access to the private encrypted key, then *changing* the passphrase on our servers won’t stop that attacker. You’ll have to re-encrypt the files with a new public key. This, however, is no worse than before, in fact it’s the same. If your passphrase was compromised, you’d have to re-encrypt files with a new passphrase before the attacker could get at the files.

[Author]

Posts