This topic contains 124 replies, has 2 voices, and was last updated by 
-
AuthorPosts
-
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.
FredHowever, this solution isn’t ideal for people who don’t want ANY plaintext versions of their files on their hard drive.
There are two solutions for you and Svante touched upon one if I understood him correctly.
- Folder mirroring. Let’s say you have several confidential folders on your hard drive – Tax Returns, Bank Statements, Client Files and so on. You then tell AxCrypt that these are Secured Folders. This’ll cause AxCrypt to encrypt them automatically. You then have your cloud upload everything with a .AXX extension (if your cloud provider allows such functionality). The alternative is to duplicate those folders – like Tax Returns but add a word like Secured after it: Tax Returns (Secured) and create a little script on your PC to only copy .AXX files. The final idea would be to use Windows File History to only backup .AXX files to a particular volume. You then sync your cloud folders to that encrypted volume. You could even have a virtual hard drive in windows like the J: drive for example.
- Encrypted cloud. I know several people on here have recommended them and they’re the easiest of solutions when you can’t trust your existing cloud. They work on all sorts of devices (PCs, Macs, Androids, Windows Phones, Blackberry, iPhones, iPads, Linux) but they’re paid-for solutions. With an encrypted cloud the cloud provider doesn’t keep the keys and they encrypt everything locally (it’s done transparently). If you forget your password then you’re f****d, you can only delete your account and start again. It’s not like Google Drive where you can Reset Password. They’re also expensive. The cheapest individual plan is 8.33€ per month going up to 20€ per month. The two main ones are Tresorit (has the most apps, easiest to use) and Spideroak One (fewest apps, more for glaciated backups).
I have colleagues who use encrypted clouds and then use software like AxCrypt to encrypt the extra-sensitive material. It’s unnecessary to twice encrypt things in my opinion, and bordering on the paranoid, but I don’t know what sort of material you’re encrypting and I don’t want to know either: that’s your private business.
I use AxCrypt for the occasional file and if I want to share a confidential file with a friend I use my cloud to create an encrypted link which only the friend can access. The recurring cost of such clouds might be prohibitive for you and they’re nowhere near as cheap as AxCrypt which only costs 3€ per month compared to 8.33€. You might also be tied into an existing cloud which makes migration hard.
CarlI have a category of files that I never want others to see (for example financial information). I have others I am willing to let immediate family members see but not other family members who use my computer. However I keep track of the passwords (password manager, paper, memory, etc.) that is my choice, it is under my control. If I choose a less secure method that is my choice. If I choose a more secure method that is my choice. V2 makes me rely on someone else which in my mind makes it less secure (yes I can choose a poor security method to keep track of passwords but that was my decision and not dictated to me by a system I do not know how much I should trust (I am not saying Axcrypt folks are not trustworthy–but I do not know them, do not know their security practices, etc.. )
I like to be the one who makes the trade-off between security and convenience.
It is only a ” behavioral security risk” if I choose to make it so.
Having multiple passwords is only less secure if I choose to make it that way.
DesmondSorry Carl, you’ll have to use the old unsupported version of AxCrypt or search for some other encryption software.
It’s an old discussion and AxCrypt have made the position clear.
SvenHi all!
I am one of those feeling bereaved by version 2. Here is the scenario to illustrate the point:
A relative (a brother in law) and I set up a scheme where we deposited SHTF files (last wishes in case of premature death etc) encrypted with v1, using individual password/key as well as a common key file. The encrypted files were deposited in a shared cloud folder, the individual passwords/keys deposited and exchanged physically in sealed envelopes, and the common key file is known only to us. (Of course we trust each other not to open the envelopes until absolutely necessary!) That way we could both know that, should the need arise, the other party could gain access to the information. We could also, relatively easy, make changes to the information and upload a new version, without the hassle of having to exchange physical print-outs. Also, the information should be more than secure enough for our purposes.
Now, with v2, as soon as we touched our deposited files the other party was “locked out” which blew this scheme. Despite both having IT MSc degrees we did not fully understand (yes: severe user error – a fact nevertheless) that that would be the case. Now we have (temporarily?) had to abandon that method, and find something else.
Please note that – as far as I understand – the key sharing method in the premium version does not help, as part of our scheme was the ability to keep the information securely deposited until the other party opened the password/key envelope. (Please correct me if I am wrong.)
Also please inform me if such, or similar, a scheme is, in some way, possible with the free v2.
ReggieAlso please inform me if such, or similar, a scheme is, in some way, possible with the free v2.
No, what you want to do is not possible in version 2.
You would have to revert to version 1.7 to use a unique password on each 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.
ReggieThe 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.
I think what Sven was hoping to achieve is a method of distributing a file that would be inaccessible until a sealed envelope was opened.
It’s still an issue of trust because there’s nothing to stop his friend opening the envelope but at least opening the envelope would be detectable, if signed and taped.
Opening the file shared using key-sharing would be undetectable and I can only think that this was what Sven hoped to achieve when he said:
<p style=”text-align: right;”>“Please note that – as far as I understand – the key sharing method in the premium version does not help, as part of our scheme was the ability to keep the information securely deposited until the other party opened the password/key envelope. (Please correct me if I am wrong.)”</p>
Sven@Reggie:
Yes, you have correctly understood what I want to achieve (and did achieve with v1). The envelope can be checked, and actually gives us mutual trust, as I need not “blindly” trust my friend. We both, mutually, know he can not have peeked into the files (and vice versa for what he has deposited and trusts me with).
I do the same on occasions when I deposit a house key with my neighbours. It is handed over in a sealed package. Should any situation warrant entry they can break the package, and if not (which is of course the norm) I get it back intact, knowing that they have not entered, and they need not wonder if I am suspicious of them.
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.
Captain QuirkSo as you can see, Svante, there is a still a strong demand for the features that Version 1 provided, that Version 2 does not. With all due respect, why can’t you just update Version 1 to account for the outdated and insecure SHA-1 algorithm? I know you want to focus and spend your time and energy on Version 2, but there are many people for whom Version 1 meets their needs and desires, and for whom Version does not. :-(
Captain Quirk* Version 2
Hello Captain Quirk!
Yes, we know there’s demand for those features. There are several reasons why we don’t meet them:
1) Version 1 still meets the requirements! As is.
2) We don’t think it’s a good idea, i.e. we do not want to promote bad security practices. Self-decrypting files for example.
3) We don’t have the resources, and we’re not getting any income back at all from work done on version 1.
4) If there really was a high demand, the source code is available, so anyone with the appropriate skills can fix it.
As to your specific request about the use of SHA-1 in AxCrypt 1, it’s non-trivial to fix since it breaks compatibility. Then, as far as I know, our use of SHA-1 is not among the scenarios where it’s a problem. I.e. in our specific case, SHA-1 still works fine and is still a good match for the purpose. That being said, I’d never recommend using it in a new product of course, but there’s not enough incentive to update our old software. If there was a real risk for security breaches, then it would be a different matter.
The problem with SHA-1 is that a collision attack is becoming economically feasible in 5-10 years. This, however, does not really pose a very large security risk for AxCrypt. We use SHA-1 for password derivation (here the attack is meaningless), and for HMAC-SHA-1, a keyed verification of the file integrity using SHA-1.
Let’s assume for the sake of argument that it’s trivial to compute a SHA-1 collision and thus our HMAC is easy to forge. What is the effect? What can an attacker do?
He or she can modify your encrypted data, without AxCrypt flagging this immediately.
What’s the effect? That someone can destroy your files, and you won’t notice it until the decompression fails because of the ruined data, or you find garbage in your word or excel file, or it won’t load etc.
The net effect of the above worst-case scenario for SHA-1 is that the strong HMAC reverts to a regular checksum. I.e. a sanity check of the contents, but not immune to nefarious modifications. Bad enough, but not bad enough to warrant an emergency fix in essentially unmaintained stable software.
Remember that the data is still encrypted, and it’s the encrypted data that can thus be modified, without a strong check. Your data is still securely encrypted.
This is completely different from the more important reasons to stop using SHA-1 SSL certificates for example, where a collision may enable you to forge a certificate, and thus produce false certificates.
CodyCaptain Quirk, there isn’t a strong demand for version 1 features.
Regrettably there are a couple of sockpuppets who are calling for version 1 features; i.e. multiple people, one of the same, trying to inflate the popularity of version 1 features to get their own way. The true number of unique people who want per-file passwords is probably fewer than 10. Analysis of publicly available Google reCAPTCHA usage tends to confirm this.
The reality is that the overwhelming majority of people are satisfied with version 2 and those who aren’t can use version 1.
It’s pointless for AxCrypt to divert valuable resources to add another feature to AxCrypt 2 which will cause inordinate amounts of confusion between the old and new paradigm.
AxCrypt need to focus on getting the software 100% solid; e.g. eliminating all possibility of null-byte errors. Adding additional complexity to the software increases the possibility for coding error, risks irreparably destroying the reputation of AxCrypt if things go wrong and increases the attack surface of the software.
If people want per-file passwords then AxCrypt 2 isn’t for them. Implementing a hybrid option would confuse and remove the value proposition of version 2.
AxCrypt is, and always has been, software for the average computer user. Offering too many options, and the ability to shuttle between symmetric and asymmetric encryption, will confuse the average user and they’ll move to something simpler.
If you’re an expert then you won’t be using AxCrypt unless you value the convenience. If convenience is important then you wouldn’t be using per-file passwords.
Having per-file passwords greatly increases dissatisfaction if and when somebody forgets their password and can’t get back in.
Experts, or people who want per-file encryption, should look at different software designed specifically for their needs.
RobertMCody, great post!
The current beta of GPG4Win 3.0 supports symmetric encryption using a password. If using multiple passwords is really that important, why not try that? It’s free, open source and actively maintained. Yes, there’s a learning curve but we’re not talking trigonometric functions here! Learning to use the software should be easy for “average” PC users. (Similar packages are available for the Mac and Linux but I don’t know if they support encryption with a password.)
https://wiki.gnupg.org/Gpg4win/Testversions
For sharing, I actually prefer the AxCrypt 2 procedure to GnuPG because it’s easier to explain to others. It’s simpler and no one needs to create a key pair. Unfortunately, PGP/GnuPG still isn’t that widely used, even after a quarter of a century.
-
AuthorPosts
