Forum Replies Created
-
AuthorPosts
-
Hi Michel,
Jeremy points out the gist of the matter.
The “why” for most of the information should be obvious, but let’s expand on the encrypted private key. Just as Jeremy states, it’s serves as a backup should your device be lost or destroyed. More importantly, we use it keep it synchronized across devices so if you have two PC’s or a mobile phone, we’ll automatically download the private key to your device so you don’t need to keep track of it.
As to the security, Jeremy formulates it perfectly: “Having the key escrowed is no different to uploading an encrypted file to the cloud. If somebody can break into the encrypted private key then they could also break into the file without the private key. It makes no difference.”
You’re mistaken when you say “another people need only my public key to decrypt what I’ve encrypted with my private key“. And it’s not a matter of opinon ;-) Think about it. It doesn’t make sense. Your public key, is… public. Non-secret. If that was used to decrypt what you encrypted with your private key – where’s the security? It’s exactly the other way around.
It’s the public key that’s used when sharing with someone, but it’s the private key that is needed when someone shares a file key with you.
The public key of someone, perhaps yourself, gives anyone the capability to encrypt. But only the holder of the private key can decrypt that data. That’s why the private key is called private, because it’s private i.e. secret. It’s what enables you to decrypt something encrypted with your public, non-secret, key.
Hello Draftmission and Jeremy,
First – we’re unfortunately not likely to support direct payment via Swedish banks, or even Swish, in the near future. The reason for this is that each payment integration carries with it quite a bit of work. It’s not trivial, regardless of what the various providers claim. There is quite a lot of work involved with ensuring and recording a payment, calculating and handling of VAT, financial reporting, receipt creation etc. Just getting the agreement approval forms filled out for Swedish banks is a lot of administration. Sweden is a very, very small market for us so…
Second – Bitcoin we’d like to implement, and we will as soon as our payment provider Stripe supports this for european companies. Direct cash payments are unlikely to be supported, for the simple reason the manual handling of such payments costs more than the yearly cost…
Hello Vishal,
I am very sorry to hear that you apparently are the victim of a hacker ransom attack against your files.
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 a hacker has chosen AxCrypt as the tool to perform the ransom attacks that appear to plague mostly Turkey and sometimes other countries.
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, and have them follow the money and Internet trail to the hacker. Since others appear to be in the same situation, you may want to contact media in order to make this problem more widely known, and also gain the possibility of a group action of all the victims against the hacker.
We cannot help, We are in no way involved, and there is no way to open the files without the passphrase used.
Please read http://blog.axantum.com/2012/07/axcrypt-used-for-ransom-attacks.html for a longer discussion of what we know about this affair.
Hello Michel A,
It’s a little unclear what your question is. If you are asking literally how to open an encrypted file without knowing the password, the answer is you can’t. That’s what AxCrypt is made for.
Hello Michel,
It’s an important question to have a good answer for, so we’ve updated https://forum.axcrypt.net/documentation/technical/ with this information.
Hello Hank,
Thanks for your input!
Hello albatros,
Thank you. In general, there is some work to do around progress and notifications. It’s always quite hard to do this clearly. Also, it appears many are annoyed by notifications, so perhaps it should not be in the tray, but in the app. Anyway, thanks!
Hi Dave,
Glad it worked out for you!
For others reading this – it’s a really good idea to write down the password used on paper and store it in a secure place. That the password search succeeded here was due to the fact Dave could limit the number of possibilities to a few thousand. If it gets just a bit more complex, it’ll just take too long (years, centuries, eons, lifetime of universe, longer…).
Hello,
To download the 1.7 version of AxCrypt from http://www.axantum.com you have to do so from the site directly, *not* from a direct link. (Technically, the referrer of the request must be http://www.axantum.com, in practice this means you should browse the web site and click the link on the web site in your browser).
Thanks Dave!
Hello Albatros,
Yes, you’re right. It *is* a bit confusing… But that is how it works right now. We’ll be changing this. Thanks!
Hello Laurent,
AxCrypt is made for the following situation:
An encrypted file is made available to the attacker. As long as your password is strong enough, it should withstand all attacks.
What we store on the server, is… an AxCrypt encrypted file. So, if our server is successfully attacked and data is leaked, what the attacker gets are encrypted files.
That being said, your password *is* passed to our servers, but it’s only kept in memory temporarily. Nevertheless we feel the usability enhancements made possible by this outweighs the concerns.
We try to be very open what we do and don’t do.
Hello Dave,
Yes, there is a simple and ugly brute force app available. Please send a request to support@axcrypt.net and we’ll send you the info.
Thank you, Thor!
Hello Gulliver,
You pose some relevant and interesting questions.
Let me first state that AxCrypt does not use Cloudflare, or any similar service. We try to keep the number of components and services used to a minimum, partly to minimize the attack surface.
We try to be very open, in fact all of the core encryption code and the entire Windows Client is published as open source. We also physically separate our content server (www.axcrypt.net) and our account server (account.axcrypt.net) also so we can keep the server with user data as “clean” as possible.
Although we could manage most functionality technically without requiring password authentication over the Internet, some services we could not. What we have done is to actually take a decision – we *do* trust SSL. Although like any protocol it can have bugs, and there are known cases of various vulnerabilities being exploited, it still in protects much of the web. Also, most of the exploits require code injection (typically by way of physical hardware appliances) into major ISP communication centers. That’s beyond the scope of essentially all attackers except governments.
To me, it sounds a little strange that you would prefer to establish routines which involves recipients of encrypted data to click executables sent to them (self-decrypting files), while being worried about SSL security. To me, using self-decrypting files, and especially asking others to routinely expect to receive such files, with the added complication of communicating the password to the file over a *more* secure channel than SSL, does not make “security sense”.
Advocating users to click attachments to run executables is a perfect way to create a huge attack vector to your users.
How do you communicate the password to the files between users? If you are in the same office, I guess verbally in a secure room with all phones and other equipment with microphones physically turned off would work. But remotely? More securely than SSL?
Anyway, we are certainly considering a mode of operation where passwords would never leave the users computer, but it will limit and complicate things in many scenarios.
For now, we actually do trust SSL.
-
AuthorPosts
