Forum Replies Created
-
AuthorPosts
-
Hi Rob,
Our Dr0pbox detection is based on ad hoc observations, as dropbox has to our knowledge not published any documented ways to detect it.
Is it a new installation of dropbox?
Hello,
You should be able to drag folders into the secured folders window – provided it’s actually a real folder. You may need to click the ‘broom’ icon to actually encrypt the contents.
As for sub folders, sorry – we don’t support that just yet.
Hello marttin,
This happens when the account password (the first you enter) does not work to actually open the file. This typically happens after upgrading, creating an account (or resetting the password to an existing account) with a different password than that used for the file.
Unless you have disabled the function, such a file will only ask you once for the original password because when you enter the correct password, the file is automatically upgrade to version 2 – and using the AxCrypt ID account sign in password.
Thanks Ron,
Noted!
February 15, 2017 at 23:49 in reply to: Dropbox> My AxCrypt> files get encrypted, folders don't. #5509Hello Rob,
Yes – right now we don’t support recursive operations. For now, you’ll have to add each folder as secured. We’ll be introducing sub-folder operations as an option in the future.
Hello Raul,
Yes, you most likely have something called Lavasoft Web Companion installed (you may not know it). See https://forum.axcrypt.net/support/faq/#lavasoft-crash .
February 15, 2017 at 21:51 in reply to: I can't get my trial version of Axcrypt to respond to my request for decryption #5506Cuppajoe,
Backups. Always backups. Regardless of encryption, AxCrypt, etc. Backup is your *only* protection against data loss. Backup your original until you’re satisfied AxCrypt works. Then always keep backups of your encrypted files.
Hello Caroline,
You need to actually send the file, after sharing the key with the recipient. We can’t know what your preferred mode of communication is, so we don’t send it.
How you send the file is up to you – email, share it via Dropbox, carrier pigeon or whatever ;-) But you need to first give the recipient access to open the file *when* he or she gets it, and *then* send it or share it with the recipient.
February 15, 2017 at 16:34 in reply to: I can't get my trial version of Axcrypt to respond to my request for decryption #5501Hello Cuppajoe,
It’s really, really hard to know what your issue is. Can you please be more specific? Best is if you can send a screen shot.
Hello,
We don’t support self-decrypting archives in version 2 for the following reasons: https://forum.axcrypt.net/blog/avoid-self-decrypting-files/ .
Nobody needs anything *installed* on their machines if you want to share files or send them to others. They *do* need AxCrypt. Which they can get as a bundled executable + the data (i.e. self-decrypting), or like it works now, they download or get the standalone version of AxCrypt. No installation required. Plus the encrypted file of course.
Version 2 does not share passwords via a server. That’s not how it works. It works using strong public key cryptography. You just enter the email address of the user who should be able to open the file using the “key sharing” feature. Then you send or share the file. No password sharing required.
Hello Anonymous,
Please send a support request to support@axcrypt.net, and include screen shots showing both the file(s) in question listed in Windows Explorer with details, and another showing the error message you’re getting from AxCrypt.
Hello Rudi,
The harm in using different strong passwords is that it makes it harder to use. This increases the threshold. However, that’s not what you stated initially. You wrote: “I use different paswords for banking-private-word-excel files and super private files“. The superlative ‘super’ I took to mean that you had assigned different ‘security levels’ to these files. ‘Private’ and ‘super private’ so to speak. I don’t see any harm in making all the files benefit from the ‘super private’ level. With AxCrypt 2 that’s really easy to do – in fact it’s pretty much the only way to do it!
The other scenario, sharing with other persons, is implemented in AxCrypt 2 using public key cryptography made really easy to use. You share the key to the file with another AxCrypt user by adding his or her email to the list of recipients, and he or she can open it with their own password. No need to share passwords.
Hello Rudi,
We do listen, trust me, we do. However, we do not have unlimited resources, and must prioritize. We may not agree on the priorities, but that’s up to us. Or to you – AxCrypt is open source, add the feature you want, or pay someone to do it for you if you don’t have the skills personally. Then ask us to add it to the product which we may do if it’s a good change or for example something on our own to-do list that you just can’t wait for us to fix.
About different passwords. Unfortunately, this is just plain not a good idea. Please consider – what is really the benefit of using a weak password for anything? What is the harm in using a strong password for everything?
About reverting from 2.1.x to 1.7.x. You should decrypt all files opened with AxCrypt 2, as the file format is automatically upgraded and this file format is not recognized by AxCrypt 1.7.x. Then, re-encrypt with the old version afterwards.
Hi Simone,
Thanks for your analysis. Your raise some interesting points. I think you’re right in that the changes are so great, that old users lack continuity, and thus risk feeling uncomfortable with it.
We’re working on this, but one fact is that new users are at least as happy with the new version, as old users are with the old – at least from comments and support questions we get. Almost all issues relate to old users upgrading. So, we really see signs that the new version is a good product, and that it in fact meets the same basic need. But old users have gotten so used to it, and habits are hard to change. If we had received any significant revenue earlier, it would have been a more gradual process of course but now the fact is that it was essentially unchanged for 15 years, now finally we’re actually doing something with the product, moving it forward. But the first step to upgrade, is perhaps a little more of a leap ;-)
Hello all,
Lots of good things said, and unfortunately some strong misconceptions about what we do, have and store.
Let’s start, briefly, with the hash issue. Yes, we use SHA-512. No, we don’t hash your password as such with it and store it anywhere. We use SHA-512 for two things – a HMAC, that’s a cryptographically strong checksum that ensures that we can be sure that nothing in the encrypted file has been changed. We also use it for password derivation – this is a process whereby we take a variable length typed password, and produce a fixed length (128 or 256-bit as the need be) value to use for the actual encryption algorithm. It’s essentially just another representation of the typed password, and we never store this anywhere.
What we *do* have on the server, is a private key encrypted with your password using… AxCrypt. Now, what’s the scenario AxCrypt is specifically made for, and actually deemed secure (provided the password is good enough) by all who have examined AxCrypt? It’s the case of an AxCrypt-encrypted file being accessed by an unauthorized individual. So, what can an attacker gain from the server? An AxCrypt-encrypted file, encrypted with your password. That’s exactly what you’re trying to protect in the first place. So either AxCrypt is strong enough to withstand the attack, in which case it doesn’t matter which file the attacker gets hold of – no go. Or, your password is weak, or AxCrypt is, in which case it doesn’t matter which file the attacker gets hold of – your data is not secure. The point being, what we keep on the server is no more sensitive than any other AxCrypt-encrypted file. And they are presumably not sensitive at all.
-
AuthorPosts
