@ehheh1000: I completely understand the perspective you come from. Ensuring the highest level of security should, indeed, be the bedrock of any encryption tool. Your trust, and the trust of the entire community, is paramount to me. I want to stress that every design and default-setting decision I make with VeraCrypt is made with security in mind and in complete transparency.
That being said, while the overhead from RAM Encryption may be minimal on many of today’s systems, especially high-end ones, I have seen firsthand from troubleshooting and user reports that it can indeed be non-trivial on low-end or older hardware. Even a small overhead can translate to noticeable performance degradation or increased battery consumption in some situations, especially on low-end notebooks. Such side effects might deter users who aren’t prepared for them.
@enigma2illusion: Your proposal has merit. However, I'm cautious about implementing features or changes by default that may have unexpected outcomes for a segment of users, even if that segment is small. A majority of VeraCrypt users may not frequent forums or read release notes in detail. It is, therefore, essential that any new defaults don’t surprise or inadvertently inconvenience them.
Given this, one approach I'm considering is adding a step in the installer or upon first launch, where users are informed about RAM Encryption and its implications. They can then make an informed decision to enable or disable this feature based on their understanding of the overhead and usability limitations. This way, we ensure that users are aware of the changes VeraCrypt might introduce to their system behavior. I will include this in the TODO list for the 1.27 version.
@isvik:
The process mitigation policy (not to be confused with memory protection) was indeed introduced to enhance security by preventing unauthorized code injections into the VeraCrypt process.
While WindowBlinds is a legitimate software aiming to customize the appearance of the Windows UI, from a strictly technical perspective, its method of applying themes involves process injection. In the eyes of VeraCrypt's mitigation policies, it's indistinguishable from malicious attempts at code injection.
To maintain the security of VeraCrypt, I've made a deliberate choice not to allow exceptions or provide a method to disable the process mitigation policy. I understand this may impact the visual consistency of your OS interface, but I hope you recognize that this decision stems from the necessity of maintaining the highest level of security for VeraCrypt users.
❤️
3
👍
2
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have uploaded to Nightly Builds folder the Windows build (1.26.7) that I will publish tomorrow as official 1.26 release. Compared to 1.26.6, it implemented a minor enhancement to RAM Encryption to implement better derivation for encryption keys and use less outstanding value for the memory allocation tag: https://sourceforge.net/p/veracrypt/code/ci/f90d472ee9bd090704b2f950d2aa86baf6488d54/
As usual, tests are welcomed even if there should not be any issue.
MOD NOTE: Fixed typo of 1?.26.7 to 1.26.7
👍
1
Last edit: Enigma2Illusion 2023-09-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@enigma2illusion: Thank you for your feedback and for pointing out the typo.
I've uploaded the official 1.26.7 release files to Sourceforge. However, I encountered an internal error when trying to upload files to Launchpad, which hosts the files linked on the official download page. As a result, I haven't updated the download page yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@idrassi Thanks again for your hard effort and work you put into VeraCrypt. I just want to point out in the changelog it still says libzip 1.10 and not libzip 1.10.1.
edit: It's fixed now.
Last edit: Mikael 2023-10-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@sorrow1: Thank you for pointing out the error. The libzip version was correct in the HTML Release Notes, but not in the README.TXT file. I've corrected it and uploaded a new file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@enigma2illusion Version 1.27 could be as long as 3 years away. @idrassi, Perhaps in the installer, have a page that states that encryption of keys in RAM is now on by default because of Elcomsoft's software, and also stating that having encryption of keys in RAM will disable hibernation and all the other ramifications, and that it will degrade performance slightly, and then perhaps some mention of possible other consequences. Then, an option that is already selected, saying "Encrypt keys in RAM (default)" or "Do not encrypt keys in RAM" or something like that. It would be interesting to see how many users complain on the forums about whatever problems they're facing because of it. Mind you, I wouldn't doubt it if Elcomsoft or some other company created a device that, when inserted into the usb slot, would access the Windows password and decrypt it, but I guess autoplay would have to be turned on. I'm sure there are some users who wish they had done their homework and searched the options and made sure that encryption of keys in RAM was on, who faced a lot of problems because of it. It's not really a big deal to just enable it by default, right? If a user then starts noticing the problems you mentioned, then it can be disabled.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@ehheh1000: I completely understand the perspective you come from. Ensuring the highest level of security should, indeed, be the bedrock of any encryption tool. Your trust, and the trust of the entire community, is paramount to me. I want to stress that every design and default-setting decision I make with VeraCrypt is made with security in mind and in complete transparency.
That being said, while the overhead from RAM Encryption may be minimal on many of today’s systems, especially high-end ones, I have seen firsthand from troubleshooting and user reports that it can indeed be non-trivial on low-end or older hardware. Even a small overhead can translate to noticeable performance degradation or increased battery consumption in some situations, especially on low-end notebooks. Such side effects might deter users who aren’t prepared for them.
@enigma2illusion: Your proposal has merit. However, I'm cautious about implementing features or changes by default that may have unexpected outcomes for a segment of users, even if that segment is small. A majority of VeraCrypt users may not frequent forums or read release notes in detail. It is, therefore, essential that any new defaults don’t surprise or inadvertently inconvenience them.
Given this, one approach I'm considering is adding a step in the installer or upon first launch, where users are informed about RAM Encryption and its implications. They can then make an informed decision to enable or disable this feature based on their understanding of the overhead and usability limitations. This way, we ensure that users are aware of the changes VeraCrypt might introduce to their system behavior. I will include this in the TODO list for the 1.27 version.
@isvik:
The process mitigation policy (not to be confused with memory protection) was indeed introduced to enhance security by preventing unauthorized code injections into the VeraCrypt process.
While WindowBlinds is a legitimate software aiming to customize the appearance of the Windows UI, from a strictly technical perspective, its method of applying themes involves process injection. In the eyes of VeraCrypt's mitigation policies, it's indistinguishable from malicious attempts at code injection.
To maintain the security of VeraCrypt, I've made a deliberate choice not to allow exceptions or provide a method to disable the process mitigation policy. I understand this may impact the visual consistency of your OS interface, but I hope you recognize that this decision stems from the necessity of maintaining the highest level of security for VeraCrypt users.
I have uploaded to Nightly Builds folder the Windows build (1.26.7) that I will publish tomorrow as official 1.26 release. Compared to 1.26.6, it implemented a minor enhancement to RAM Encryption to implement better derivation for encryption keys and use less outstanding value for the memory allocation tag: https://sourceforge.net/p/veracrypt/code/ci/f90d472ee9bd090704b2f950d2aa86baf6488d54/
As usual, tests are welcomed even if there should not be any issue.
MOD NOTE: Fixed typo of 1?.26.7 to 1.26.7
Last edit: Enigma2Illusion 2023-09-30
Hi @idrassi
Release Note typos:
FYI: I take the README.TXT and copy/paste into Word document to look for issues.
Missing Uppercase to start sentence
Last edit: Enigma2Illusion 2023-09-30
Hi @idrassi
I already had RAM Encryption enabled, upgraded to 1.26.7, rebooted, mounted volumes and no issue to report at this time.
Last edit: Enigma2Illusion 2023-09-30
@enigma2illusion: Thank you for your feedback and for pointing out the typo.
I've uploaded the official 1.26.7 release files to Sourceforge. However, I encountered an internal error when trying to upload files to Launchpad, which hosts the files linked on the official download page. As a result, I haven't updated the download page yet.
@idrassi
Thank you Mounir.
When you get the chance, please update the local Release Notes so the correction is included on the local PC Release Notes for the future releases.
@idrassi
Also, please include the correction to the CHM file in version history.
@idrassi Thanks again for your hard effort and work you put into VeraCrypt. I just want to point out in the changelog it still says libzip 1.10 and not libzip 1.10.1.
edit: It's fixed now.
Last edit: Mikael 2023-10-01
@sorrow1: Thank you for pointing out the error. The libzip version was correct in the HTML Release Notes, but not in the README.TXT file. I've corrected it and uploaded a new file.
@enigma2illusion Version 1.27 could be as long as 3 years away.
@idrassi, Perhaps in the installer, have a page that states that encryption of keys in RAM is now on by default because of Elcomsoft's software, and also stating that having encryption of keys in RAM will disable hibernation and all the other ramifications, and that it will degrade performance slightly, and then perhaps some mention of possible other consequences. Then, an option that is already selected, saying "Encrypt keys in RAM (default)" or "Do not encrypt keys in RAM" or something like that. It would be interesting to see how many users complain on the forums about whatever problems they're facing because of it. Mind you, I wouldn't doubt it if Elcomsoft or some other company created a device that, when inserted into the usb slot, would access the Windows password and decrypt it, but I guess autoplay would have to be turned on. I'm sure there are some users who wish they had done their homework and searched the options and made sure that encryption of keys in RAM was on, who faced a lot of problems because of it. It's not really a big deal to just enable it by default, right? If a user then starts noticing the problems you mentioned, then it can be disabled.