Forum Replies Created
-
AuthorPosts
-
Hello Nora,
Normally, no. What the secure delete does is simply open the file using normal file system calls, then overwrite the contents of the file with random data, issue an instruction to the operating system to flush (i.e. actually write the data to disk). This will stop normal file recover tools quite cold.
However, there are many caveats depending on the technology used underneath. If you have Windows “shadow copies” enabled, there may be older copies available. If you have Windows compression enabled, the actual data written is likely not what the program thinks. If the drive is a SSD device with wear leveling (most do) then special software may be able to recover data, although it’ll be hard to re-assemble whole files without a lot of work. There are other special situations too.
As has been evidenced by the actions of various security agencies in the last couple of years, the only apparently trustworthy data-sanitation tool is a power drill, sledge hammer or high pressure compactors.
AxCrypt secure delete will suffice for most reasonable situations. If you want a more secure non-destructive tool complement with periodic use of tools such as Eraser (it will overwrite all empty blocks on the disk until the disk is full). If you think the man is after you, see above suggested power tools.
Hello Nora,
Sorry, but right now there is no official support for Linux. For what it’s worth, the last time I checked the Windows-version was actually runnable albeit a bit ugly on Linux when compiled using the MonoDevelop etc.
For the future if there’s sufficient interest we may see if it’s possible to port the Mac-version to MonoDevelop and Linux. On of the problems with Linux is the fragmentation of distributions. One doesn’t just support Linux. There’s no such thing. There are a zillion different Linux-distributions. We’d literally have to support perhaps a dozen builds and then test them… Doesn’t seem likely to happen unless someone sponsors the development and maintenance unfortunately.
A third option is that someone from the community pitches in and uses our open source to build a Linux version and the various distribution support required.
Hello Gary,
Thank you for taking the time!
Before making your final judgement, please consider that we might actually have plan ;-)
Your main gripes are around the fact that things work differently. This does not mean that you can’t do the same tasks as before! Just that it’s easier. I.e. different. Different is not the same as worse.
In order to share encrypted data with others with AxCrypt 1, you had to share passwords, and keep track of them. No more! You can still share securely.
There is no longer any need to share passwords in order to send or share files securely with others. AxCrypt has a key sharing feature letting you add recipients by email address, who when they receive the file can open it with their own AxCrypt password.
Key sharing embeds the shared key into the file. The file must thus first be key shared with the recipient, then sent or file shared. Please note that AxCrypt does not share or send the actual file. To see a quick instructional video explaining how to use key sharing, please view https://www.youtube.com/watch?v=9z3KOZD-Yks .
So, you can share your encrypted files with your editors or whomever without the need to have a zillion strong different passwords (if the passwords are just slight variations on each other, or made according to some system, what’s the point of encrypting them in the first place?).
You’re then upset because we do assume that if you’re at your computer you want to work as seamlessly as possible with your encrypted files, instead of entering passwords all the time. Actually, this was always present as an option in AxCrypt 1 – we just made it the standard. This is a different, but better, way to work and keep your files secure. It helps you use a really strong and good password.
AxCrypt 2 works just like your email software or most other password-protected systems. You sign in once, and remain signed in until signed out. Just like you can read many emails without entering the password every time, AxCrypt will do the same. The files are still encrypted, but your password is remembered until you sign out of AxCrypt.
Finally you say that we’ve removed the anonymous rename function. We didn’t. Try right-click, “AxCrypt” | “Rename”.
Some of these functions do require a paid subscription, but after so many years I had two options: let AxCrypt go and abandon it, or try to get some revenue and keep developing. I chose the latter.
I’ve written some longer blog texts on some of these subjects, please feel free to read:
https://forum.axcrypt.net/blog/use-of-different-passwords/
https://forum.axcrypt.net/blog/leaving-computer-axcrypt/
Hello dilbrb,
AxCrypt 2 works just like your email software or most other password-protected systems. You sign in once, and remain signed in until signed out. Just like you can read many emails without entering the password every time, AxCrypt will do the same. The files are still encrypted, but your password is remembered until you sign out of AxCrypt.
Thank you Stan!
Hello Julie,
If you could post a screen shot, or send it to support, it may help us identify the problem.
AxCrypt 1 and 2 have no problems as such with 64-bit Windows. If, however, you are using something else than Windows Explorer such as Total Commander, you may have problems because for example Total Commander is not 64-bit, but 32-bit.
It sounds like you’re running AxCrypt 1, since you mention XP.
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.
September 14, 2017 at 10:14 in reply to: Keep file names from showing on Sign In page even after secured files are closed #7851Hello nobody,
No, we don’t have that option right now. You might want to read https://forum.axcrypt.net/blog/leaving-computer-axcrypt/ for a discusion about the general scenario – someone walks up to my computer with AxCrypt installed / running / signed in etc.
The summary reads: We think you should activate your screen saver if you walk away from a device with information on it confidential enough to warrant encryption in the first place.
Hello Julie,
As mentioned in the Premium support request you also sent in, it should work. Please provide more details as described there, and we’ll try to fix it via support. It’s not a lack of the function when using the Free plan. It should work.
Hello “veracrypt progamer”,
I’m afraid your response has little or nothing to do with the original poster’s question.
FYI AxCrypt 2 is compiled with Visual Studio 2015, and targets and require .NET Framework 4.5. AxCrypt 2 is not supported on XP, but will run on Vista with .NET Framework 4.5 or better installed.
The original poster’s issues have absolutely nothing to do with this though.
You are of course welcome to participate in these forums, as long as you are constructive and polite to all parties. But we’d all appreciate it if you did your research before posting.
The full and complete source code for the Windows application is available at https://bitbucket.org/axantum/axcrypt-net . In other responses I’ve also posted links to relevant information concerning the rationales, reasons, and technologies used.
September 12, 2017 at 22:06 in reply to: online account need: it confused me…malware? spyware? trojan? #7839Hello “veracrypt programer”,
We are entirely transparent in what we do, and why, and how.
Please read:
https://forum.axcrypt.net/documentation/technical/
https://forum.axcrypt.net/documentation/privacy-policy/
https://forum.axcrypt.net/documentation/license/
https://forum.axcrypt.net/documentation/security/and perhaps most importantly for you, the source code:
https://bitbucket.org/axantum/axcrypt-net
And, in actual fact, you don’t need online access. You can disable it with “–offline” or “Always Offline” in the menus.
Hello Joe,
Please contact support for this by emailing support att axcrypt dott net .
Do include screen shots of the various error messages, not too closely cropped so we can see the Windows Explorer and full AxCrypt window.
Hello Greg,
Yes, technically we can add auto-anonymous-rename and we can display the real file name when signed in (what you suggest is what we do – we keep the original file name in encrypted form in the encrypted file).
Auto-add is on the to-do-list, as is another related issue:
https://bitbucket.org/axantum/axcrypt-net/issues/310/add-anonymous-rename-to-options-for
https://bitbucket.org/axantum/axcrypt-net/issues/151/add-restore-original-name
We do display the original file name in the recent files view. To do so from Windows Explorer is possible, but non-trivial because it requires some communication back and forth between the shell extension and AxCrypt, so this we probably won’t do. We might do something inside the app though to facilitate finding the right file when it’s not in the recent file window.
Hello Paul,
No, AxCrypt is a file encryption software, and only encrypts files. However, since the original file name is included in the encrypted information, the encrypted file can be renamed to anything while the original name will be still be restored on decryption. There’s also a function to do this simply called anonymous rename.
Hello Marvin,
There’s something not quite right with your description of events. The typical sequence of events are identical, but named differently. There’s no difference really between AxCrypt 1 “asking for a password to open the file” and AxCrypt 2 “requiring you to sign in to open the file”. In fact, I believe the keystrokes are exactly the same!
AxCrypt 1:
- Double click the file.
- AxCrypt pops up a dialog asking for the password.
- Enter the password, hit “OK”.
- The file opens.
AxCrypt 2:
- Double click the file.
- AxCrypt pops up a dialog asking you to sign in.
- Enter the password, hit “OK”.
- The file opens.
The one scenario where you’d be asked for a password twice, is if you’re opening a file encrypted with a different password than your sign in password, encrypted with AxCrypt 1 or with AxCrypt 2 by another user or yourself, but with a password *reset* (not *change*) between. In the case of an AxCrypt 1 file, it’s a one-time thing since we’ll upgrade the file to AxCrypt 2 and use the sign in password. So next time it’ll work as usual.
I’m guessing that “I even changed my AxCrypt.net password to my preferred encrypt code and that allows me to sign in online” is not quite correct. Our logs show a password *reset* on September 7, which would explain the “but I still must use the zxzxzxzxzx on my PC to then access my encrypted file“. If this is the case, of course you must! A simple password reset, which only requires access to your email inbox to succeed cannot restore access to previously encrypted files!
-
AuthorPosts
