Forum Replies Created
-
AuthorPosts
-
Helllo jsampson45,
Yes, the “Save As” question is relevant.
It’s on the to-do list, or at least to-investigate list, see:
https://bitbucket.org/axantum/axcrypt-net/issues/139/set-working-directory-to-original
https://bitbucket.org/axantum/axcrypt-net/issues/92/encrypt-extra-files-in-the-work-folder
Thank you Iain!
Hello Jorge,
I have no idea of the quality of the estimation of your password manager, but 32 characters is indeed very long. If it’s not a simple phrase in english or based on some other system that once known by an attacker reduces the search space, it’s a very strong password. With or without extra iterations.
So, yes, that will thwart any realistic attack.
Hello Dean,
Start by clicking “Save”. This reduces the complexity a bit. Save it in “My Documents” or a similar place.
Now you have a file in the file system, and you can try to open it with double-click, or more appropriately, right-click it and select AxCrypt | Decrypt. I don’t think Turbotax actually opens files by double-clicking, so you may have to import it or otherwise get it “into” Turbotax.
Hello,
When was this last opened, and when was it originally encrypted (or, more precisely, with what version of AxCrypt)?
Hello Jorge,
We don’t focus on length, but on complexity. That said – at least 10 characters, digits and symbols.
The second question can’t be answered in a precise way. AxCrypt uses a dynamic number of iterations to strengthen the effective password length with 12-14 bits (very approximately and it depends on the encrypting computer). The speed of the “super computer” is affected by the amount of money spent on it.
The better questions are:
1) What is the effective length of your password? Our password manager generates strong passwords at around 90 bits.
2) How many bits effective key length / second do you think the presumed attacker has a budget for?
Hello Steve,
If you look a little further down on the pricing page, you’ll find the following text:
“All pricing excl. VAT which will be applied for EU customers according to EU rules on order. We do not support VAT-free sales to VAT-registered companies within the EU. To start using AxCrypt you have to sign up for an account. A 30 day trial of AxCrypt Premium is included and will start when you activate your account.”
So there’s nothing wrong with the pricing, it’s just that you need to pay VAT on top of the €24.
Hello Dwight,
You write “I prefer the V1 approach which allows for different local passwords“. I may have mentioned before in this thread, but I wrote a longer essay on this here: https://forum.axcrypt.net/blog/use-of-different-passwords/ . I really think you should reconsider when you say “I want my different client files to have unique passwords“, but of course in the end – you decide! I can only advise. We’ll of course adapt to user demands, as long as it is not detrimental to overall security. We may indeed implement password based key sharing, if we can figure out a way to make it easy to use.
Hello kz,
Re “dokan”, well actually it does require tinkering with system files, very much so. It’s a kernel mode driver implementing a user mode file system on Windows. That’s what I mean with tight integration with Windows. While it does offer many advantages, we don’t want to go down that road for a number of other reasons. For example, it’s not possible to make a non-privileged portable desktop app since it requires installation of a kernel mode driver. This means it can’t be run or installed on a computer without permanently modifying the operating system and it requires administrative permissions. AxCrypt can run as a pure portable standalone without installing anything. Also, although it’s fairly mature, it’s scary to install a kernel mode driver and be responsible for that and there’s also a big risk with incompatibility with future versions of Windows. It requires something entirely different to work on the Mac and/or Linux, so maintenance and development costs goes up. These are just some of the reasons why we’ve decided to not do it like that.
A more likely scenario for us is indeed to implement a folder mirror, where we work as normal, and just copy / delete files between them as they appear and disappear – but only encrypted files to the secure folder, not plaintext files. There are some UX challenges with that, but we’ll see.
Thanks for the input!
Hello Dean!
You should have received a confirmation of the payment through our payment processor, Stripe in this case. We have received your payment, and your Premium subscription is active.
You write “Can anyone help me get back into my files?“. Premium is *never* required to open your files on your computer. We will *never* lock anyone out of their data due to lack of payment, that’d make AxCrypt ransomware which it’s not of course.
It’s not entirely clear exactly where you are stuck. Please provide more information about your problem, If you can send a screenshot showing where the problem is, it often helps us understand.
How to take a screenshot is explained here: https://support.microsoft.com/en-us/help/13776/windows-use-snipping-tool-to-capture-screenshots .
If you do not want to post screenshots here, submit a Premium support request by signing in to https://forum.axcrypt.net/ or by sending an email to support att axcrypt dott net .
Hello kz!
Thank you ;-)
You make a very valid point about the sync folder issue with cloud storage providers. I’m not sure how Boxcryptor et. al. handles this case, but I believe they integrate very differently and more tightly with the host operating system, working as file system filters and similar. We integrate very loosely, which gives us many other advantages, but this can be an issue if you *really* don’t want any plaintext to hit the cloud ever.
I should mention though that it’s not quite like you say. The problem is not opening and working with encrypted files in a cloud service sync folder. The problem is when you drop new unencrypted files in such a folder, until you tell AxCrypt to encrypt them. Working on encrypted files is not a problem (as long as you don’t actually use AxCrypt | Decrypt). Working with files through double-click is safe in this scenario too.
We can probably never, with the current level of operating system integration, guarantee that no files ever hit the cloud since it essentially means we have to interfere quite harshly with the cloud service sync software. It must either never see the real file system, or we must be able to tell it to stop syncing or forbid it to sync files as they appear while they are unencrypted.
We’re certainly aiming at improving this, and many other things!
Hi kz and Captain Quirk,
Just a real-world example of why I really think our straight Premium subscription is more honest and fair. The following just arrived in my e-mail box. It’s 100% real, but since I don’t want to throw dirt around, I’ve redacted the actual software name:
Thank you for using the [redacted] by [redacted]!
It’s been a while since you purchased this plugin, and your license key will expire on May 10, 2017. Don’t worry, if you’re currently using the plugin on your website, it won’t stop working when the license key expires, and it’s perfectly fine to keep using it as long as you want!
However, if you’d like to continue to be eligible to receive updates and support for the plugin, you’ll need to renew your license key, and we’d like to offer you a discount of 25% off* the regular price! To renew now, please visit [redacted] and follow the instructions shown.
So, we bought a “one off” license a year ago. Now, we can no longer update it – regardless of security issues, incompatibility issues or whatever. But we can get a new license key for another year at 75% of the original “one off” cost.
I like our subscription better. The reason why a subscription *feels* worse, is because it’s honest! It tells you upfront, in no uncertain terms, that if you want to actively continue using the software with all the bells and whistles, here’s what the yearly cost is. Our subscription is also just for certain features. You have free upgrades forever even if you don’t purchase Premium, so while we’re alive, we’ll keep updating it for new versions of the platforms and fix bugs and any security issues.
Would you rather be hoodwinked like with the above, or have it out plain to see from day one?
Hello Hjalmar,
Aha! I see ;-) That kind of fingerprint!
Well… The idea behind the AxCrypt PKI is that you trust the AxCrypt server (yes, I know, but we’re willing to make well-defined compromises to achieve a higher level of usability). So, if you know the recipients e-mail address and know that the entity behind this email is who you want to communicate with, that should suffice.
Maybe I’m still not understanding? I will admit I respond perhaps a little more rapidly than your quite advanced suggestions require…
Thanks Hjalmar,
Handling the key pair and licensing can absolutely be done with a zero-knowledge protocol, like yours or similar to it. Actually I think it can be made even more simple, by simply generating the key pair locally and only upload the encrypted private key, never generating or encrypting it on the server.
The main problem you have already pointed this out – the online password manager. It gets so much more complicated and risky if the data is kept locally, and it completely (well, almost) removes the use of it with a simple web browser – which actually is a very important use case for it! Downloading and uploading updates is of course possible, but inefficient after some time, and a little risky.
Another problem, but it can be handled, is the invitation process. Where Alice invites Bob to a document, and Bob does not have an account. What we do now, is we generate the key on the server, and keep it encrypted with a machine key utnil Bob sets his own password, at which point the key is re-encrypted with that password. Of course, that can be tweaked to only use it as a temporary key until Bob sets his password at which point we update the key pair on the server with a locally generated one. This would minimize the exposure, even if not remove it completely.
Of course – if you don’t use the password manager or ever sign in on the web, we don’t need to see the password.
However, it does get a little more complicated for users to understand what’s going on, and for us to support them.
We have relatively few users actually requiring zero-knowledge at this time.
Concerning fingerprint support etc, it requires a little bit of extra consideration. Please read my blog post on the subject for a longer discussion: https://forum.axcrypt.net/blog/encryption-and-biometrics/ .
Further comments welcome. We will be developing along these lines, but we some other priorities currently – most notably Mac OS X support which is coming soon!
Hello Carl,
I’m not following. The Google Authenticator is still about proving identity – not possessing a secret. Remember that AxCrypt is designed to handle the following scenario:
The attacker has access to the following:
– One or more encrypted files, and the original decrypted originals for all but the file(s) being attacked.
– All the source code and technical documentation for the application.
– Tools and skill to use, write and adapt code to try passwords/keys without interference of operating system or server authentication – i.e. entirely offline and under the attackers control.
– Lots and lots of hardware (think custom built supercomputers) and money, vast amounts of money (many, many millions of $).In fact, the only things the attacker is not assumed to have is the password, and you (so you can’t be forced to reveal the password).
Therefore, having various additional stronger “authentication” methods does not really make sense, since we assume the attacker can get round those. We still want AxCrypt to stand strong. And it does, provided you use a sufficiently strong password, which we try relatively hard to help you with.
-
AuthorPosts
