This topic contains 3 replies, has 1 voice, and was last updated by 
-
AuthorPosts
-
Alden20Hi,
I am writing about an improvement that I requested a long time ago and that is still not implemented: the possibility to change the temporary directory used for decryption.
As I mentioned a few years ago, there is a vulnerability in the way files are decrypted: when you double-click on a file encrypted with AxCrypt, it is decrypted in a temporary directory on the hard drive and then this file is the one that it is commanded to open with the default application. Once the application has been closed, the temporary file is re-encrypted if there has been any modification to it and the decrypted temporary file is deleted.
The problem is that if during the time we are editing the file there is, for example, a power outage and the computer is restarted, the file remains decrypted in this temporary directory on the hard drive and someone could get to it.
That is why I suggested at the time that the possibility be given that the temporary directory used by AxCrypt can be changed so that it can be pointed, for example, at a ram disk or a VeraCrypt encrypted mounted unit so that in this way, if causes a system reboot, it is not possible for someone else to get to the original decrypted file.
Regards.
Alden20What’s more, what doesn’t make sense is that you have a file encrypted with AxCrypt on a VeraCrypt encrypted volume, that is, fully secured, and that when you open it, it is temporarily decrypted in an insecure folder in C:\Users\my_user\AppData\Local\AxCrypt\… which is completely decrypted and unsecured, from my point of view this is a security vulnerability.
If the AxCrypt-encrypted file, which is hosted on a VeraCrypt-encrypted volume, were to be temporarily decrypted on the same volume, it would be fully secured as it would be decrypted on a volume that is encrypted and is protected against possible system crashes (because, in this case, the volume would have been closed automatically).
I’m sorry, but I don’t understand why it is so difficult to be able to change the temporary decryption path, I don’t know your application inside, but I understand that it should be something simple to do (obviously as long as no other decrypted file is being edited), you just have to tell the application that what it is doing now in the established temporary decryption path, do it in another, nothing more, in principle it should be a very simple change to implement in the code.
It’s just that I don’t understand how this security problem that I told you about, and that I notified you of several years ago, hasn’t been resolved yet. As I’m telling you, I don’t think it’s very difficult to implement.
I’m sorry, but as long as you don’t fix this vulnerability, I can’t buy the premium version…
Alden20Hi again,
In my opinion, I think AxCrypt should ideally use a ramdisk as a temporary decryption directory, for two reasons:
1- A security reason: currently, if the system crashes while a file is being edited, the temporary decrypted file remains stored on the hard drive, as I mentioned in my first message. The file stays there until, I imagine, the “Clean up” button is pressed in the application, which I imagine will physically delete it.
This problem would be solved using a ram disk, in this way, if the system crashes, there is no need to worry that the decrypted file has been saved on the hard disk, because being a ram disk its content has automatically disappeared when restarting the system, and in this way there would be no need to worry about deleting the file later from the application with the “Clean up” option.
2- A performance reason: a ramdisk is much faster than an SSD, therefore all the continuous encryption/decryption operations that are done in the temporary directory would be much faster and would increase the performance of the application, especially when handling very large files.
You could use the ImDisk Virtual Disk Driver (http://www.ltr-data.se/opencode.html/#ImDisk) component within your application to automatically create a ram virtual disk and use it as a temporary decryption directory. This component is open source, it would not cost you anything. You could integrate it into the application so that AxCrypt would create and use this type of disk automatically, with all the advantages that I have explained above (being open source, you should only publish the changes that you have made in it, not the rest of the code of your application).
The idea would be that the user could set, within AxCrypt’s configuration options, how large he wants the ramdisk to be created based on his computer’s memory.
A mixed system could even be used: if a file to be decrypted is larger than the free size of diskram, it could be temporarily decrypted on the hard drive (but allowing the user to select the path where to do it). If it does not exceed that size, the ramdisk would be used (that is, the ramdisk would take precedence over the physical disk).
Regards.
Alden20Please review the following article:
https://support.atakama.com/support/solutions/articles/43000623211-how-the-atakama-filesystem-works
Of course, I don’t expect AxCrypt to be as complex to use its own VFS (virtual filesystem) as Atakama, I understand that it would be quite a complex change to implement, but I do hope that you understand what the article means with the vulnerability of storing the temporary file decrypted on the hard drive and why it should be done in memory (reason to use a ram disk as I mentioned before).
Regards.
-
AuthorPosts
