Forum Replies Created
-
AuthorPosts
-
Hello Rob,
Maybe you haven’t looked into the key sharing feature + secure folder with AxCrypt. It sounds like the right thing for your scenario.
Each user has his/her own password that (s)he sets individually. Users of a particular folder on a network drive for example, designates it as a ‘Secured Folder’ in AxCrypt, and then sets the users that all files in that folder should be openable by. That’s it. Existing files will be set to include the recipients, and new files will automatically also have the same recipients.
The normal workflow once you’ve set up the secured folder and the default recipients for that folder is trivial. No nightmare!
(Currently an inconvenience is that the configuration of the recipients is kept local in each users computer, and thus each user who creates new files do need to set up the same list of recipients. We’ll improve this in the future.).
Hello Franz,
As you say – it doesn’t matter for the original poster. However, I always like to learn new things.
I do know about the 50,000 vs. 100,000 iterations for Office 2007 vs. later, but I did not realize that the XLS file format was sophisticated enough to handle in a backwards compatible manner a different encryption technique.
I.e. Excel 2003 password protects using the known weaker encryption, while Excel 2007 (or later) can password protect using the newer stronger encryption – in the same file format, such that Excel 2003 can actually recognize that it can’t decrypt a .XLS file enrypted with Excel 2007. Presumably it displays a mesage to the effect that it can’t open the file because it’s been saved by a newer version of Excel then?
Browsing the specification for XLS files and office encryption actually I can’t really tell. Wow – those specs are complicated! What I do see even with a brief browsing is that there are about a zillion different ways “password protection” may actually be performed on a document. If the default is changed for example, a regular user would never notice. The installation default for later versions of office is indeed AES-128/SHA-1, but there are many caveats there too. In comparison, the AxCrypt technical specification is a lot easier to analyze and implement. One way to compare is that the Office Document Cryptography Structure specification is 107 pages (including 7 pages index), the AxCrypt Version 2 Algorithms and File Format is 12 pages (without any index) including rationales.
Ok, that was quite off-topic! Sorry ;-)
Hello Rob,
I’m afraid you lost me a little bit. What’s the point of encryption if there is no secret key involved somewhere?
AxCrypt almost does what you say, you can share the embedded file key with anyone with an email address, and they can sign in using their own password. But they still need to enter and know that password.
others, from earlier versions of the program are filetype “xls”
That used to be true with Microsoft Office versions 2007 and below.
The file was of type .xls, which is an older format, and that was the format *before* Office 2007.
Hello Old Bob,
This means that the Excel-file itself is password protected by Excel. This has nothing to do with AxCrypt. Google the error message, and the top hit is: https://support.microsoft.com/en-in/help/321147/error-message-the-password-you-supplied-is-not-correct .
Apparently, you have both password-protected the Excel file and also then encrypted it with AxCrypt. You’ll have to remember the Excel password – or get a cracker. Contrary to AxCrypt, Excel password protection can usually be cracked ;-)
Hello Gary,
AxCrypt 2 asks you to sign in to your account, which AxCrypt 1 did not. We now use a single sign on model where the same password is used to sign in to our servers and to protect your files. The password that you’re being asked for is the password to your account, which you probably created when you first installed AxCrypt 1.
If you do not remember the password to your account, you can always reset it. This is not a way to recover encrypted files! It’s only to allow you to sign in to the AxCrypt app and web. The new password will be used to encrypt new files. Go to https://account.axcrypt.net/Home/PasswordReset to do this, or you can also go there from AxCrypt with File | Options | Password Reset .
If you open files encrypted with a different password than your sign in password, which often is the case directly after upgrading to version 2, you will be prompted for that original password. If the file was encrypted with version 1, it will then be automatically upgraded to version 2 and to use the new sign in password which means you won’t be prompted again for the old password.
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!
-
AuthorPosts