Forum Replies Created
-
AuthorPosts
-
Hello Anonymous,
This depends on the version of AxCrypt you’re using – but it also signifies a serious problem with the file. The meaning is essentially that the file has been modified after it was encrypted. That’s not good.
You can’t really ‘fix it’. With AxCrypt 1.x you can chose to ignore it, but no guarantees are given as to the correctness of the decryption. Go to http://www.axantum.com/ and check the section on registry settings for instructions how to instruct AxCrypt to ignore the error.
March 18, 2017 at 15:48 in reply to: When an encrypted movie is played does it all have to dycrypt before it plays? #5760Hello MickyD,
Yes, the entire movie is decrypted before playing – AxCrypt is not always optimal for encrypting/decrypting large streaming media since the decryption process does not support streaming consumers such as video players.
That it’s faster the second time is due to AxCrypt not having cleaned up the decrypted file. You should have a red ‘Broom’ icon in this case, and if you over over it you’ll see an explanation. AxCrypt cannot wipe and delete the decrypted file until it’s sure that it’s no longer being used by the ‘receiving’ application, and sometimes this even means you have to manually tell AxCrypt when is a good time to clean up by clicking the broom when red.
Hello Richard,
Please take a screen shot of the situation.
How to take a screen shot is explained here: https://support.microsoft.com/en-us/help/13776/windows-use-snipping-tool-to-capture-screenshots .
March 16, 2017 at 22:41 in reply to: Encrypting multiple files different passwords using version 2 #5755Hello Brian,
You are welcome. Although we try to make AxCrypt about real security within well-defined boundaries, if we can provide both real security and a good feeling, we’ll try to do so.
Hello Raphaela,
AxCrypt 2 works better with OO, because it has a semi-manual handling of closing files.
The command line parameter documentation for AxCrypt 1 is found at http://www.axantum.com/ .
March 16, 2017 at 22:00 in reply to: Encrypting multiple files different passwords using version 2 #5752Hello Brian,
Thanks for your input! I think the most common problem here is not really using different passwords or not, but the AxCrypt 2 behavior of remembering the password so you don’t need to / have to type it every time. This existed in AxCrypt 1 as well, but was optional (“Remember this passphrase for decryption”).
We’ll be adding an option to require the password for every time a file is opened, not because we really think it’s a good idea or necessary, but by popular demand ;-)
Hello,
No, SSL cannot be intercepted by anyone in a privileged position – unless you by that mean you, yourself or someone else with administrator permissions on your local PC who can install any certificate in your certificate store to mount a man-in-the-middle attack. But this entity does not need to break into SSL! Anyone with admin permissions on your system can get at your secrets there in a number of easier ways. Corporate firewalls cannot terminate an SSL-connection without you being aware of this, and if they instead mount a MITM “attack” we’re back at previous argument. A trusted root certificate needs to be installed in your device.
SSL *is* used to protect both secrets and economic resources. Very few will use VPN to connect to their Internet bank.
You have tested the wrong site, http://www.axcrypt.net – no secrets are ever passed to that server (that being said, we’re in a continuing discussion with our hosting provider about that. It’s a known issue, but not really relevant to this discussion).
The correct site account.axcrypt.net , which currently receives a ‘B’ rating, due some minor issues that may be caused by the user having older browsers. This is a tradeoff between what users are allowed to connect. If we set up too strong a cipher suite, some users with older browsers can’t even connect. Users with modern browsers will not use the older problematic ciphers. But thanks, we’ll take another look at this and see if we can setup a suitable cipher suite giving us the ‘A’ rating, without locking out users.
Adding another layer of security may, or may not, increase the level of security. We may indeed do so in the future but adding layers also increases complexity and difficulty of analysis. Peer review is great – but it’s not a guarantee. There have been problems found in just about any protocol ever published, and the advantage of SSL/TLS is that there are literally thousands of researchers trying to find flaws, and publishing when they do. And they’ve been doing this for a long time.
Better the devil you know, than the devil you don’t still applies.
Hello Pedro,
Yes, I read the list, and much of it is indeed sound advice but it must be taken in context.
The truth is far from “anybody in a privileged position could log the password“. That’s simply not true. Period.
The various leaks and errors made in SSL have been adressed one after another, as they are revealed. That’s not to say there aren’t any more – but it is to say it’s not that easy to design a secure protocol and I’d much rather use a well-known fixed protocol, than a less used and less analyzed, and less fixed protocol. Even worse – make up my own.
That a protocol has no known leaks does not mean it’s secure. That’s the problem with security. You can’t typically prove security, only demonstrate insecurity.
Properly used SSL/TLS is still trusted to protect a majority of world secrets, and world economic assets – and in general does a pretty good job of it, since both you and me and perhaps a billion of other users still have our money in our respective bank accounts without it being stolen by way of a hacked SSL/TLS connection with our banks for example.
The incentive to successfully hack and intercept an arbitrary SSL/TLS connection in economic terms is absolutely gigantic. It hasn’t happened. That’s one reason I trust SSL/TLS for AxCrypt use.
If, however, you have any indication that we’re not using SSL/TLS properly (no one is perfect) – please let us know and we’ll fix it immediately.
Hello Pedro,
It’s always hard to separate conspiracy theory from real vulnerabilities in these scenarios. Our current view is that SSL/TLS is a good choice for AxCrypt. Better the devil you know, than the one you don’t, is part of it. We’re aware of various issues with SSL/TLS but we believe they are not generally relevant to our situation.
We currently have no plan to use SRP or any other mechanism, for establishing a secure connection between client and server.
Of course, this may change, but that’s the current viewpoint.
Hello,
There is a password, it’s the password you use to sign in to AxCrypt with. But, that’s your personal secret password you should never share with anyone.
To share an encrypted file, select the ‘key sharing’ option, and enter the recipients AxCrypt ID (email address). This will cause a shared file key to be embedded into the file. You can then send the file to the recipient by whatever means.
When the recipient signs in to AxCrypt with his/her own password he/she will be able to open it.
See videos at https://forum.axcrypt.net/ .
Hello Janae,
Please send screen shots of the situation, along with a detailed description of what happened, and what does not happen now to support att axcrypt dott net.
Hello Will,
If you do not remember the password to your old account, you can always reset it. This is not a way to recover encrypted files! It’s only to allow you to sign in to the new AxCrypt. The new password will be used to encrypt new files. Go to https://account.axcrypt.net/Home/PasswordReset to do this, or you can also go there from AxCrypt with File | Options | Password Reset .
Unfortunately, if you do not know the password you cannot open an encrypted file. That is what AxCrypt is made for!
Please check the FAQ at http://www.axcrypt.net/support/faq/ for more information.
Hello Laurent,
Please read https://forum.axcrypt.net/blog/use-of-different-passwords/ .
Hello scott,
When you start AxCrypt, you are asked to sign in. The password used for sign in is the password used to encrypt and decrypt files as long as you are signed in.
It’s just like your email program. You sign in once, then you can read and write email without typing the password every time – until you sign out, or are automatically signed out.
AxCrypt works the same. You remain signed in until you sign out, or are signed out – which happens when you lock the computer, log out of Windows, the computer goes to sleep or is shut down.
March 9, 2017 at 08:01 in reply to: Forgot my new V2 AxCrypt sign in password after opening and converting a V1 file #5725Hello Justin,
I am very sorry to hear this. It appears you have understood correctly, what you describe is a very likely explanation of what has happened.
Unfortunately, we’ve had many similar incidents with V1, apparently it’s not altogether too uncommon to set a password encrypt a file and forget it.
For this reason, we’ve now made users enter the password no less than three times before we actually use it to encrypt anything. This has significantly decreased the number of such incidents, but it appears it happened to you anyway.
We also have the ‘show password’ option on by default to reduce the risk of typing something else that is expected.
Still, since it happened, again we need to clarify this even further.
We will be adding some form of first-time use information that you’ll have to ‘sign’ with your password where we’ll inform of the importance of not forgetting the password, as well as of how critical it is to use backups. We’ll also be adding a similar dialog when a V1 file is first converted, informing of what is happening.
Once again, I’m sorry.
On the another note, I’ve written a blog post about multiple passwords, here: https://forum.axcrypt.net/blog/use-of-different-passwords/ .
-
AuthorPosts
