Forum Replies Created
-
AuthorPosts
-
Hi again skipro (like the tag by the way, I read it as ski-pro ;-),
All your points are essentially valid, and I certainly agree that it’s kind of the point of encryption – if you don’t know the password you can’t decrypt. But… This is where reality makes itself known, and some users are just not careful enough, and while it’s not our formal responsibility to protect these users from themselves, the fact is a lot of our users are attracted by the simple operation – and thus also have pretty vague ideas about what’s really going on.
Still, glad you feel better for getting the rant off your chest, and as I said – in princple I agree.
We’ll get to this function soon enough I hope, you’re not the only one asking!
Hi skipro!
I mostly agree, it’s just that I’ve been on the end of trying to explain to user that he just irrevocably destroyed both all of his files and his computer OS installation (encrypted too much + lost password). In that situation, it’s tough to have to say “well it’s at your own risk, and you made the mistake”.
So, while we can’t make it foolproof, we need to make it almost… So, all of your ideas are under consideration, and we will implement it.
The current plan is to move all options to a single page of advanced options, with some extra precautions against changing them – i.e. a warning dialog and explicit user consent by typing your password or something like that. We don’t really like options at all, but some are unavoidable and this is probably one of them.
So, we won’t need to reconsider, we just have to get to it. Right now mobile apps are taking a lot of our available development time. We’ll get there.
Hello Patrick,
Good points, all. We actually already have an issue logged for password based key sharing ( https://bitbucket.org/axantum/axcrypt-net/issues/131/add-sharing-password ) , and you’re probably right that manually imported public keys should be possible to use in the Free version, so I’ve added that to the issue list of things to do: https://bitbucket.org/axantum/axcrypt-net/issues/233/manually-imported-public-keys-should-be .
We’re also considering making all key sharing free in the future – that would also solve this issue ;-)
Thanks!
Hi Patrick,
Actually that feature is there so advanced users and users without Internet access can import and export keys, and also feel safe about it. You still need Premium to share a file key at this time, even if manually imported. We should definitely consider making it possible to do so in the Free version. Thanks for pointing this out.
The use of the function is to do what the server otherwise does, when you share the key to a file (we don’t share actual files) by typing in someones email, what happens is we get the public key from our server and then use it to share the file key.
Hello Stefan,
This can be because Dropbox has changed something about how it installs itself (there’s no documented way to really know if Dropbox is installed, so we essentially make some ‘intelligent’ guesses).
It can also be because you don’t have Dropbox installed, or have customized it in a way that we don’t take into account.
Can you tell us more about the version of AxCrypt and Dropbox and if you’ve done any custom things with Dropbox?
Hello Sign In,
No, you don’t have to use two passwords – at least not after an initial time where older files are upgraded to AxCrypt 2 encryption and the password you use to sign in to AxCrypt with.
So, assume you have an older file “My Secrets-txt.axx” encrypted with password “secret123” and using AxCrypt 1.7.
1) You download, install AxCrypt 2.
2) You create an account ‘bob@secrets-r.us’. You set a new password here, ‘!fEllive8Vibution’ (a much better one).
3) You sign in to AxCrypt two with ‘bob@secrets-r.us’ and ‘!fEllive8Vibution’.
4) You try to open “My Secrets-txt.axx”.
5) You’re presented with a password prompt, because your new AxCrypt account password doesn’t work for this file.
6) You enter the old password “secret123”.
7) The file opens AND is at the same time automatically re-encrypted using AxCrypt 2 and the new password ‘!fEllive8Vibution’.You then sign out of AxCrypt and come back a day later.
1) You double-click your “My Secrets-txt.axx” file.
2) The new AxCrypt 2 sign in window appears. You sign in with ‘!fEllive8Vibution’.
3) The file opens without any further ado, since it was automatically re-encrypted with the new password in step 7) above.Hello Patrick,
It works as you say, but you must realize that nothing is sent to the recipient when you enter his/her email to share with. We just share the file encryption key *in the file* using the recipients public key.
So, encrypt the file, share the key using the recipients email address as identifier, then send the actual encrypted and key-shared file to the recipient (or share it using a cloud service).
If this still does not help you, please provide a detailed set of steps we can use to reproduce your problem.
Hello Agostinho,
It’s on the road map as mentioned, we just don’t have a timeframe. It’s not a technical difficulty, it’s how to add such a powerful feature without unwary users burning their fingers on it ;-)
Hello md,
Yes, the standalone works just like the installed version (minus Windows Explorer integration, i.e. double-click and right-click in Windows Explorer).
Yes, we ask for an email address then too, since it might be a good idea to synchronize keys with a new device, or enable Premium functionality if you’ve paid for that (we keep track of subscription status on a server).
However, if you don’t have Internet access, you will still need to enter an email but we won’t require a registration. We’ll accept anything that looks like a proper email.
You can also force AxCrypt to never attempt Internet connection by starting it with the –offline switch.
So, yes, the standalone really works standalone.
Hello Reza,
Please see the FAQ at http://www.axcrypt.net/ .
Hello skipro,
No, it’s not a technical problem, it’s a usability problem. We’ve had too many users making mistakes with the very powerful function of recursive folder encryption (i.e. Encrypt from c:\ for example…).
We’re considering ways to make the function more failsafe, while still useful.
Hi Anonymous!
Thanks for the feedback, even if pretty harsh. Still, we need to hear that as well.
It would actually be nice if you could elaborate a little more about why you H**E it ;-) From the post, the only concrete thing you mention is that we don’t display a special progress window while encrypting many files. I’m also a little suprised that you say you encrypted the same folder multiple times, since even if no progress window as such is show, the files are encrypted, and Windows Explorer will update continously as the files are encrypted.
Anyway, even if you don’t like it – tell us more about what you don’t like, since it makes it possible for us to consider what changes we should make.
November 7, 2016 at 15:10 in reply to: Sometimes Save of crypted fails, remaining the not crypted copy in %appdata% #4572Hi Roberto,
First of all – please update and keep your AxCrypt fully updated, you’re almost up-to-date, but not quite.
The next time this happens, please follow the instructions here immediately after the problem surfaces: http://www.axcrypt.net/blog/send-complete-error-report/ .
This will give us a chance to understand more about just what happens, and thus fix it.
Thank you for reporting this!
Hi Yngvar,
First of all – you can run AxCrypt 2 entirely offline, with no online registration using the –offline switch. You’ll still have to provide something that looks like an email address, but anything will do. It won’t be used for anything as long as you stay offline. In this mode AxCrypt will not attempt any form of network communication.
As for maintenance of version 1. Should there after all these years surface some real security issue with it, we’ll have to consider either pulling it entirely from the site, or fixing it. It will depend on the situation. If for example a Windows update makes it incompatible, we won’t fix it. So, if it won’t run on Windows 11 or whatever next version will be called, it won’t run.
Hi Tony,
For your specific scenario – personal archive use, I really think you’re misunderstanding how AxCrypt 2 works and the value of the portable / standalone version.
This is a fully featured entirely self-contained version of AxCrypt 2 that you can store along with your AxCrypt-encrypted files. The self-decrypting function is really limited in functionality and requires you to run each encrypted file separately to decrypt, and has a fundamental built-in limit of 2GB size (due to Windows restrictions in .exe size, not an AxCrypt limitation).
I really think you’ll be much better off using the standalone AxCrypt 2 version, than the AxCrypt 1 self-decrypting feature.
-
AuthorPosts