cryptolover

SGX isn't secure at all, it has lots of disclosed vulnerabilities, just take a look at Intel's own advisories page, it lists at least half a dozen SGX issues. And those are only the ones which have been found and acknowledged. It's also Intel only and poorly documented. Furthermore, hardware based security is inherently flawed because it's hard to patch holes once they are found. It requires firmware updates, which stop being released quite quickly and carry a danger of bricking the device. I don't...

I like some of these ideas, like the password quality indicator and hiding full disk on UEFI as it wouldn't work anyways. OTOH, I don't like the idea of removing options, especially these: Short passwords are useful for quick testing and there is a popup anyways. The mouse based random generator is very important for security. Please don't remove that. As a general guideline, I don't think "dumbing down" VC's interface is a very good idea. Making it easier to use the interface won't make the users...

I'm aware the performance issues with SSD's are hard to solve without giving up on container support. How about making VC with two drivers bundled, one with better performance and no container support, and the other with worse performance and container support? An "SSD mode" option on the settings page would switch the driver on the next reboot, enabling users to choose if they want container support or fast SSd support. If they use containers sparingly, they could flip the switch when they need...

I'm not convinced asking the user to choose a mode is going to solve the problem. Users that don't read the docs will just choose a mode without understanding the implications. If you add them, please don't remove any current options.

Some of us dislike hardware based security features such as AES-NI and RDRAND because at the end of the day they are proprietary and cannot be audited to prove they work properly and don't have backdoors. RDRAND's output may be reproducible by those who know how it is implemented. That could be mitigated by mixing the generated values with other sources of entropy, but that still leaves the possibility that the very use of cryptography related instructions could trigger a backdoor (in Intel ME or...

I think the SSD performance issues can be traced to two different root causes. The first is the IRP replacement issue which has been acknowledged by the devs. This causes a general reduction of performance, but affects random access much more than sequential access. This should not visibly degrade performance to mechanical HDD levels. My theory is that there is a second issue when the SSD is completely filled with random bytes during encryption (by selecting wipe mode different from none for system...

Please don't increase the typing delay, that will be horrible for those of us with long passwords and regular keyboards. If you do, please make it an option instead of mandatory. As a side note, is there a performance benefit with "Enable extended disk control codes"?

I'm also interested in this. I suppose it might be possible by modifying the header on the new drive using an hex editor. See https://www.veracrypt.fr/en/VeraCrypt%20Volume%20Format%20Specification.html I'm not sure how that would be done since those offsets (100 and 116) are encrypted and there is a checksum on 252. Perhaps it could be edited with the OS booted and encryption would be automatically applied? I don't want to go the decrypt/encrypt route since data might be left behind on SSDs.