Forum Replies Created
-
AuthorPosts
-
Hello Natalie,
We don’t send files. We encrypt files, and share keys to files so they can be shared (by other means).
You’ll have to contact the person who wants you to send files.
AxCrypt has a key sharing feature letting you add recipients by email address, who when they receive the file can open it with their own AxCrypt password (that’s you, the recipient).
Key sharing embeds the shared key into the file. The file must thus first be key shared with the recipient, then sent or file shared (that’s the other person, the sender). Please note that AxCrypt does not share or send the actual file. To see a quick instructional video explaining how to use key sharing, please view https://www.youtube.com/watch?v=9z3KOZD-Yks .
Hello,
I am very sorry to hear that you apparently are the victim of an attack against your files using AxCrypt.
However, please understand that AxCrypt is just a tool that is used by millions of legitimate users for good purposes. I am very sad that someone would choose AxCrypt as the tool to perform such attacks.
Unfortunately in this case, AxCrypt is based on strong encryption, and it is generally not possible to crack the encryption.
What you must do is contact your local police.
Please read http://blog.axantum.com/2012/07/axcrypt-used-for-ransom-attacks.html for a longer discussion of what I know about this .
Hello Jean,
Are you using version 2.1.1526 ? This was a version that was available for about a day, which included a serious reliability issue which can cause what you describe under certain circumstances (notably, files left open when AxCrypt was automatically signed out). It was withdrawn very quickly.
If so, you would have received a pop-up message stating you must update because of this. We have a mechanism where we can flag specific versions as “bad”, either for security or for reliability. As long as you allow AxCrypt to connect to the Internet, you will be prompted to upgrade in very strong terms.
Thank you Ryan!
Hello Sven,
I do understand your scenario now. We don’t support that scenario right now, just like that. You could work around it by using a separate account for this of course. We do have plans on adding a feature where you can add passwords, and share it that way, and that might work but there are some practical issues with that need to be ironed out.
Hello Alberto,
You can use the ‘Try Broken File’ feaature. It is a little hidden, so you first have to enable the ‘Debug’ menu by File | Options | Debug, and then try to decrypt the file with ‘Debug | Try Broken File’.
No guarantees – you’re likely to get some other message, but it may help you recover part of the file.
Hello Sven,
We try to be really clear about the automatic upgrade of old files to version 2 format, but I guess we could be even clearer…
From what I understand, the key sharing feature of AxCrypt 2 is a perfect fit for your scenario. Let’s call you Sven and your in-law Bob, with email sven@one.test and bob@two.test .
Sven adds ‘bob@two.test’ as a key sharing recipient to ‘in-case-of-svens-death.txt’ . Now, Bob can open the file using his own password, without the need for a separate password in an envelope (of course Bob would keep such a backup anyway for his relatives in the case of his demise).
Bob adds ‘sven@one.test’ as a key sharing recipient to ‘in-case-of-bobs-death.txt’ . Now, Sven can open the file using his own password, without the need for a separate password in an envelope (of course Sven would keep such a backup anyway for his relatives in the case of his demise).
This also makes it easy to manage multiple possible recipients of this information, such as a spouse or child etc, should you wish to.
The only difference is the absence of the specific envelope with the separate password used for this mutual purpose, but that seems a little cumbersome I think and doesn’t really add anything. As you write – it’s still a case of mutual trust.
Thanks Stephen,
It’s the same start bytes for the legacy version 1 as well, so it should work for all AxCrypt-files.
Harvey P,
Thanks for your input, it’s much appreciated.
Just for the record, no we can’t decrypt the passwords stored in the password manager. We don’t know the password, and it’s encrypted using strong XML Encryption on the server. (Yes, in theory if our code is evil, we could – but that applies regardless of online / offline – including LastPass and 1Password. If their programmers are evil, they can get your information from your system. So you have to trust the code and the programmers. The difference is that our code runs on a locked down, single purpose server. Their code runs in the most hostile and dangerous environment known to man – privately managed PC’s).
As for the “if intercepted by hackers, allow decryption” – well, that’s just why we are strengthening the SSL configuration. And, while I know this view is not shared by all, I still would like to ask you what would you trust more:
– Encryption technology that is all pervasive, publically reviewed both from specifications and from implementation code, and used by essentially all networked devices on the planet – with known weaknesses mitigated by proper and validated configuration.
or
– Encryption technology that is closed source, proprietary, relatively new and never publically reviewed and used by relatively few users.
The former describes SSL/TLS, the latter describes the “zero knowledge” schemes used locally by for example LastPass and 1Password.
Both services also use SSL/TLS for example for signing in to your account via the web. LastPass supports the weak algorithm 3DES on their web site, so a downgrade attack could possibly succeed. 1Password has actually gone one step further than we do, and simply drop backwards compability for a lot of clients by only supporting TLS 1.2.
1Password is run on Amazon Web Services – which means that anyone with access to that infrastructure can potentially intercept data or plant code there. As you probably know, there have been several well-documented cases of national agencies gaining access to large providers infrastructure. We use physical owned servers located in Sweden.
I’m not saying that LastPass or 1Password are bad or insecure services. They are not. However, it’s not a simple equation to determine what is “more secure”. It really depends on both objective and subjective factors when you evaluate it.
Hello Harvey P,
As mentioned, there are several reasons for sending sensitive information to the server, including the use of the online password manager. One can of course argue that in itself is a problem, but we’ve made an active decision to do this in order to gain all the usability benefits we get from it.
It is by no means a trivial decision, and either way we go it has serious impact on security and usability.
Regardless, it’s important that we keep good SSL hygiene.
Hello Adam & David,
We are investigating this. The likely cause is a little too tight configuration of our SSL parameters, however although we’re sorry for the inconvenience we’d rather err on the safe side here.
The background is that since we’re relying on SSL/TLS to protect sensitive information when travelling to our server (passwords both for the account and the online password manager), it’s important that we maintain strong security. Since SSL/TLS has been under careful public (and secret) scrutiny for many many years, weaknesses have been discovered. Some are such that we really don’t want to allow such a connection, so we actually do not support some legacy “cipher suites” and protocols.
In other words – in some cases we’d rather not allow a client to connect and use a service, rather than allow an insecure connection.
One might argue that it’s the users decision, but in this case it’s just too hard to know as a user just what the risks are.
Also unfortunately, there’s no well-accepted best practices here since it all depends on the server capabilities and the level of security required, offset by other requirements as well such as performance.
So we’ve been very conservative, and may have locked some devices out. We have now amended this slightly, so perhaps you can try again and see if you have better luck.
In any case, do let us know, so we know if we should continue investigate.
Thank you Callum!
Hello Al,
Thank you for contacting us. No, we’re not that expensive ;-) We use the European Central Bank currency rates via an XML web service service, and it appears that for some reason the values were either sent by them, or interpreted by us, incorrectly. We cache these values for 24 hours, and it they were updated just before you checked and saw the surprising result.
This has actually been in operation for many years without a single problem, so it was a bit of a surprise that it suddenly just stopped working as intended!
Once again – thank you for notifying us of this.
Hello Jason!
Thanks for the input and ideas. A general comment is that when password-based encryption becomes too transparent, i.e. you don’t have to enter the password at all or very infrequently, is that that people tend to forget it’s there. Which is a good thing until… you for some reason need to re-enter the password, perhaps after moving the data to a new computer, and realize that you don’t remember it any more. That’s one of the reasons we think that it’s a good thing to actually have to enter the password at certain times, even if it can feel annoying.
We may in the future offer regular licenses instead of subscriptions, but there’s quite some work in order to do so, and we think the subscription plan in many ways is more fair. Read https://forum.axcrypt.net/blog/subscription-vs-license/ for a longer discussion of this.
Hello David,
Can you please try to browse to https://account.axcrypt.net/ from your Android device and ensure that it can establish a connection with the server?
We have recently tightened security on the SSL configuration, and there is a potential for older devices not being able to connect due to this. You have a fairly recent version though, so it should be ok but let’s start there.
-
AuthorPosts