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.
From the docs: "System encryption is supported only on drives that are connected locally via an ATA/SCSI interface (note that the term ATA also refers to SATA and eSATA)." Would this still apply if I used system encryption on an internal SATA HDD and installed it on a SATA to USB case? Would I be able to boot from it?
Do you guys have any plans to improve this? It's going to be more and more of a problem now that NVME SSDs are getting popular. Maybe you could take a look at how DiskCryptor does it, it doesn't seem to have this problem.
First of all, Mounir, I'd like to thank you for all your work on VC! That said, IMHO you shoudn't have added TPM support at all. TrueCrypt refused to add TPM support because it's security benefits are questionable. While there's no conclusive evidence, many suspect "hardware security" like TPM and RdRand to contain government backdoors. Even your own documentation says you aren't going to add TPM support: https://www.veracrypt.fr/en/FAQ.html I really hope you reconsider this, as I'm sure many of...
Bump. I'd also like to have confirmation of this.
I'm curious about the results of the Quarkslab audit. What issues have been found...
I really hope you don't remove the entire disk option, it's the only way to make...