[SvanteSpectator]

Hello Paul,

The only thing that happens is that the folders are not monitored thereafter – the files remain secured, and you can still open them and update them (although the updated files will use AES-128 instead of AES-256).

So, when you premium expires, the files in the secured folders will stay secured, but if you add new files to the folders you’ll have to manually instruct AxCrypt to encrypt them.

We will never lock you out of your information when your Premium expires, and we’ll never change the level of security for files encrypted – unless of course you modify and re-encrypt them as explained above.

[SvanteSpectator]

Hi,

Thanks for the extra info, and that *is* one strange work environment…

1 – What you mean “right-clicking an URL”? A shortcut?

2 – See http://www.axcrypt.net/blog/avoid-self-decrypting-files/ .

3 – We’re working on cross-platform, right now in beta for mobile iOS and Android apps. Next step Mac OS X, which we thing as a spinoff will support Linux with minimal extra work, so there’s hope!

[SvanteSpectator]

Hi Gabriel,

I understand the shared admin account – but you don’t leave the system signed in with admin access do you?

AxCrypt will automatically sign out when the windows account is logged out, or the screen saver goes active etc. So it should really work quite well for you in this case.

However, AxCrypt is not multi-user right now. We’ll be adding that function in the future.

It’s an extremely unusual situation – shared Admin account where you work with personal sensitive information.

So, no, it’s not perfect for that situation, but apart from the fact that it will remember your email-address (which should not be a secret for your co-admins though), it should work quite well given that you actually sign out or at least enable the screen saver when you leave the system.

If I missed anything, please let me know!

[SvanteSpectator]

Hello DaveT,

If it doesn’t it’s because it’s not installed… So, what indication do you have that AxCrypt 2.1 *is* installed? A screen shot is preferred if you can!

[SvanteSpectator]

Hi Richard,

Thanks for a long and interesting discussion. As a summary, for future viewers, I’d like to summarize and insist on the following, which fully explains all behavior:

– V1 “Keep Time Stamp” only has effect when encrypting a file for the first time. Only. Not otherwise.
– V2 and V1 has the exact same behavior when opening already encrypted files regardless of V1 “Keep Time Stamp” setting, except…
– …for the special case where V2 opens a V1 file, and causes an automatic re-encryption to V2 thus updating the encrypted file time stamp.

[SvanteSpectator]

Hi,

You might actually want to *try* these things out with the software… After all, the truth is out there – in the form of how the software actually behaves. It might be easier to understand by actually doing and observering.

You’re almost there with “Part 1”. The tech behind password change has some more nuances, but essentially you’re correct. Once a file is encrypted with V2 it’ll be openeable with any password that you change to, with some caveats about offline mode of operation and moving to new PCs. (It’ll also be openable with the password that was in effect when it was last encrypted).

You’e still not there with “Part 2”. I don’t really know how I can say this any more clearly?

– V1 “Keep Time Stamp” only has effect when encrypting a file for the first time. Only. Not otherwise.
– V2 and V1 has the exact same behavior when opening already encrypted files, except…
– …for the special case where V2 opens a V1 file, and causes an automatic re-encryption to V2 thus updating the encrypted file time stamp.

I’m afraid this is where I’ll have to leave the time stamp discussion.

I maintain that the V1 “Keep Time Stamp” registry setting was a mistake from the start. My bad. It was originally default, then I took it away because I realized it was a mistake, but kept it as a “hidden” registry setting for backwards compatibility. That was perhaps also a mistake. I should have treated it as the bug it is and just fixed once and for all. But I have now in V2. Sorry for this.

Good luck!

[SvanteSpectator]

Hi Richard,

Your steps 1 – 4 are all correct. However… Continuing….

5. Sign out of AxCrypt and Windows.

6. Sign in to Windows.

7. Double-click one of the previously V1-encrypted files opened in step 3 or 4.

8. AxCrypt prompts you for the sign in password, i.e. “ABC” above.

9. The file opens without further prompting, because step 3 or 4 above caused the V1-encrypted file to be re-encrypted as a V2-file, using the sign in password “ABC” instead of the old V1 file passphrase”XYZ”.

[SvanteSpectator]

Hi Richard,

I’m glad we’re now almost clear on how this works. But not quite. You write: “If I have NO V1 files, V2 encryption and the setting of timestamps will ALWAYS work like V1 did with KeeptimeStamp=1. Correct?”.

No. Incorrect. I’ll say it again:

– The only time the Keep Time Stamp setting has any effect is when you are encrypting a given file for the first time. So, when working with already encrypted files, V1 and V2 behave identically – regardless of the setting of Keep Time Stamp setting in V1.

Often, I keep the door open for modifying the behavior of AxCrypt according to user feedback. But this is probably one area where I’m afraid I won’t budge. Fooling around with the time stamps was always a bad idea – it just took some time for me to realize it, but that was more than 10, closer to 15 years ago.

The time stamps mean “when was this file last updated”. And that’s what it should say. Not “when was something inside last updated”. Everytime we try to “lie” to the system, we’ll get punished for it sooner or later. Therefore AxCrypt won’t lie anymore with the timestamps. If a file is modifed, the timestamp is updated.

When a file is decrypted, that is equivalent to a restore operation, and then it makes sense to restore the time stamp as well – which is what is done.

[SvanteSpectator]

Hi Richard,

You may be right that we could try to be more clear during the sign up, and also when the file password dialog is displayed.

On the other hand, you should have noticed that as you opened old V1 files, and was prompted, that just happened the once – since they are automatically upgraded to V2, and with the new sign in password.

All of this is only an issue for existing users of V1, for new users of V2 it’s all very natural and easy to use. We’re continuously working in trying to ease the transition for existing users. Not quite there yet, it’s a work in progress. It turned out to be much harder than expected.

[SvanteSpectator]

Hi Michiel,

Thanks for the feedback, sorry you’re disappointed. The self-decrypting feature of V1 was implemented over 15 years ago, in a landscape very different from now. At that point in time, malware was something that spread via floppy disks, and sending executables over email etc was not a problem. Since then, things have changed – and so has AxCrypt finally.

The replacement for the self-decrypting archive is much better – it’s the stand alone fully featured portable version of AxCrypt 2.

We’ll be continuously developing AxCrypt 2, and also reacting to user feedback, so it will certainly change in the months to come. Some features may well make it back, but perhaps in a different way than before.

[SvanteSpectator]

Hi João ,

I’m with you here, and I fully understand your reasoning. Unfortunately, not everyone can analyze the consequences like you have.

Regardless, adressing the issue of optional behavior around the sign in is high on the list of things to do. We’ll try to enable all levels, from your suggestion “Auto login with Windows”, to “Ask each and every time for the password”.

[SvanteSpectator]

Hi Richard,

The point with V2 is that you should only be using a single strong password for all your encrypted files, it is also verified in order to ensure that you did not mistype it – this is to avoid the situation where you encrypt files with a mistyped password and then cannot open them. The workflow you describe is not how it should be. I do not understand how you get there. Here’s how it should be:

1. You sign out of Windows.
2. Time passes.
3. You sign in to Windows.
4. You do things that has nothing to do with AxCrypt.
5. You double-click an encrypted file, or right-click an unencrypted file to encrypt.
6. You get a password prompt to “sign in” to AxCrypt – really to set the default password to use for the session and to verify that it’s the one you’re expecting to use.
7. The file is opened or encrypted.
8. You continue to work with AxCrypt-encrypted files or encrypt new ones.  You are *not* prompted for any password, because you are signed in to AxCrypt, and we’ve verified that it’s the right password to use.
9. You sign out of Windows, causing AxCrypt to also be signed out. Repeat from step 2.

 

[SvanteSpectator]

Hi,

We’re getting there ;-)

Let’s repeat it again – the V1 “keep time stamp option” *only* affects the situation where you take an unencrypted plain-text file and encrypt. It has no effect on the behavior when opening an already encrypted file.

Your file management will work as it should in the one situation described where V2 will actually update the encrypted file, even if you as a user only open it to view it. This is because the file *has* changed, and thus *should* be backed up again. Even if the file inside has not.

There are three situations that you should understand:

1. You encrypt a previously unencrypted file, say “file.txt” to “file-txt.axx”. This is the only situation where V1 and V2 behavior differs as a result of the V1 “keep file stamp” option.
2. You open an already V1-encrypted file with V2 the first time. This is when the encrypted file is actually updated, even if you do not actually modify and save the unecrypted file when you view it.
3. You open an already V1-encrypted file with V1, or you open an already V2-encrypted file with V2 and you do not modify it. In this case the encrypted file, and it’s time stamp, will remain unchanged because the encrypted file is not changed.

[SvanteSpectator]

Hello Philippe,

Thank you for sharing, it is indeed as you say – Lavasoft Web Companion may cause AxCrypt to crash. However, it’s not AxCrypt which is incompatible with Lavasoft, it’s Lavasoft which is incompatible with Windows.

See http://www.axcrypt.net/support/faq/#lavasoft-crash .

[SvanteSpectator]

Hello John,

Yes, that’s one of the nice things with AxCrypt 2. A changed password will work an all files previously encrypted with your AxCrypt ID (account, i.e. using your email address).

Svante

[Author]

Posts