I use TC since a long time and now I want to switch to Veracrypt. Thanks idrassi for the good work you are doing so far! If I am happy with the software it will be the first time ever that I donate money to an open source project!
I have several questions:
How do I switch from TC to VC? I already installed VC but what is next? Can I simply convert the TC sysystem partition to VC? Or do I simply have to deinstall TC? When I do that, is the system partition bootable or is the TC driver then deinstalled, too?
When I encrypted my SSD with TC I did the following: I left 10 percent of the SSD unpartitioned and I encrypted the partition. Was that wrong? Should I encrypt the whole drive or does it make sense to let 10 percent free so that wear leveling is working and the SSD has room to manage the wear? Of course I had no sensible data on the SSD before encrypting, so that should be no problem.
My CPU has AES support and my SSD is AES encrypted, but of course the speed, especially the random data speed, is really low in comparison to the non encrypted drive. Are there plans to speed up the software for SSDs? Diskcryptor for example is a lot faster on SSDs so it is possible to tweak the software.
Are you guys working with CipherShed at the moment? They are doing a TC-Fork too and it would be wasted ressources if you would do two seperate projects if you could put your work together instead...
Thanks for the help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If your TC volumes (containers, non-system partition) were created with version 7.0 and above, then you can convert them to VC format through the change password operation. This doesn't apply to encrypted system partitions (this appears to be your case). For now, the conversion of TC system partitions is not implemented and as such you have to keep TC in such case. TC and VC can run on the same machine with no conflicts so you can for example keep TC for your system encryption and use VC for containers and non-system partitions. The other options is to decrypt your system and encrypt it back using VC, but this can take a long time and it is not something that everybody wishes to do. That's why the conversion of TC system partitions in on the agenda for the next release.
Generally speaking, wear leveling is an enemy for disk encryption but its effects can be mitigated by following strict rules described in the documentation (https://veracrypt.codeplex.com/wikipage?title=Wear-Leveling). In light of these rules, leaving 10% of the SSD unpartitioned after the encryption is the wrong thing to do as it breaks the security model of disk encryption. As explained in the documentation, the obvious example if the password change operation: because of the wear-leveling, the new volume header will most probably be created in the empty 10% space and the old volume header will remain on the disk, thus leaving an attacker with a way to decrypt the data if the old password is weak or compromised. As a rule, always encrypt the whole SSD before use.
AES-NI is implemented to from that side, so TC and VC use full AES encryption speed. Can you give more details about the data speed? any benchmarks? For read operations, I don't see how TC or VC can be slow compared to other software since only the encryption layer adds an overhead and thanks to the AES hardware we use the maximum available capacity. For write operations, the TRIM operation of SSD is not blocked by TC or VC except of the hidden system, so also in this case, only the encryption adds an overhead. It would help if you have any reference or data that compares TC/VC and DiskCryptor and that gives the exact context of comparison.
The VeraCrypt project starts in 2013 long before the TrueCrypt demise and thus before the CipherShed fork. After the TrueCrypt end, I was contacted by Bill Cox who is behind CipherShed and he proposed to join his project. For me, it was more logical that people join VeraCrypt since the foundation is already here. But in cases like, it is difficult to have more that one captain in a ship and the CipherShed project went ahead. Personnaly, I have nothing against, on the contrary, I believe that the it is very good diversity in open source encryption offering and at any time CipherShed or VeraCrypt can benefit from the work done on the other project. Another point is that VeraCrypt is a pure Continental European project (well, French to be precise) while the CipherShed project is US/UK based. So, fatally, there is a culture difference that make our approaches different. With the latest revelation about NSA/GCHQ, there is strong demand for stronger encryption and VeraCrypt choose this path from the beginning with a policy of quick releases, CipherShed on the other hand has a compatibility approach that basically keeps TrueCrypt living without offering any stronger security on the short term. On the organization side, CipherShed people are doing an amazing job and things are handled professionally which is good on the long term but it makes things slower and there is no clear commitment about the strength of the encryption they will be offering in the future. Personally I remain open to any cooperation although I would have preferred that the project be managed on the development side from Continental Europe and not the US/UK for obvious reasons.
Last edit: Mounir IDRASSI 2015-01-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-04
Thanks for your looooooooooong reply! You take so much time for this project someone could think a big agency overseas would fund you! (just a joke...)
Alright, so I guess I will just decrypt and encrypt the whole SSD then.
I previously read that article but I do not understand why it is unsafe to leave 10 percent free and not permanent encrypted and how the wear leveling should work if the whole disk is encrypted. I understand that having sensible data not encrypted on the SSD and then the SSD encrypted then there is the possibility that the data is still available on some flash cells (although it would be really hard to get the data out because the controller can not be switched without loosing the data that is encrypted be default by the SSD controller). But after VC is installed all data is encrypted except the volume header (possibly) so the only problem is that you could switch out a new bootloader with an old password. Or is Windows able to bypass the VC encryption driver and write clear data to the unpartitioned 10 percent that is free? So why is it unsafe to have a wear leveling drive that is encrypted to 100 percent by VC? Then there is no other place where Windows could put data unencrypted. In the link there is not explained if wear leveling can work when the drive is 100 percent encrypted, I understood that it can't work because VC writes the whole drive full of "random" data that the SSD controller can not analyze or move so the wear leveling technology can not write data to SSD cells that have not been used much and that increases the wear drastically. So when my understanding is not wrong then leaving the 10 percent free is not a problem other than that an old volume header could possibly be reactivated. So I should keep TC for the system partition until VC can transform it to VC, otherwise I would have to decrypt the drive and encrypt it again with VC but that would be unwise cause then decrypted data might be stored in the 10 percent that is not encrypted with VC. Right? I am confused now. And some people say that modern SSDs have 10-15% spare room for situations where the whole SSD is written full so it is no problem to encrypt it to 100 percent.
Here is my system: Samsung 840 Evo + i7-5820k + GTX 970
Without TC encryption I have 540 MB/s sequential read, 520 sequential write, 98.000 direct read and 90.000 direct write like Samsung says.
With encryption and 10 percent free space I have 334 sequential read, 369 sequential write, 8421 direct read (IOPS) and 21847 direct write (IOPS).
Thats still a lot better than a HDD but I am loosing a lot IOPS.
I indeed invest a lot of my personal time on this project especially since the collapse of the TrueCrypt when the need of a strong alternative was felt more strongly. This could not happen without the support and the patience of my wife who always encourages me as she understands the importance of this work.
I would feel proud if someone thinks that a big agency is behind me as VeraCrypt is my brainchild who is growing through my dedication and my 14 years experience in the security field. This also can help people imagine what a big agency like the NSA can do with thousands of talented employees who only focus on specific tasks without worrying about their monthly paycheck...
I didn't say that it is "unsafe to have a wear leveling drive that is encrypted to 100 percent by VC". At the contrary, full encryption is a mitigation to the risks of wear-level. I don't see any confusion, you just have to take things more simply. Windows can't circumvent VC or TC. The issue is with the SSD controller who may leave cells containing old data. From this simple fact, you can build all the security threats.
I also see only the leak of the old header as the potential threat. If there were no confidential data before the encryption, then this should be the only risk.
That being said, as my experience tells me, I always define a security perimeter larger than what my current knowledge tells me to do because attacks get always better and never worse.
Of course, I'm not an expert on SSD technology and its internals. Things are advancing fast and modern controller are becoming complex so their behavior is difficult to judge without painstaking real-world tests. There are simple rules that apply to flash based storage and that helps define basic security rules. I leave to others the work of studying how modern SSDs are behaving with Full Disk Encryption solutions like VeraCrypt.
Thanks for the links and information concerning the TC benchmarks. I'll have to study the subject more in details.
Last edit: Mounir IDRASSI 2015-01-04
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2015-01-15
I already answered but I think there was an error because it was not published.
Short form: I asked for the feature to transform the TC system partition to a VC system partition (decrpyting on an SSD and then encrypting again is not safely possible). I think you are already working on that, but just to show you that more people would ike that I asked for it again.
Thank you very much!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I use TC since a long time and now I want to switch to Veracrypt. Thanks idrassi for the good work you are doing so far! If I am happy with the software it will be the first time ever that I donate money to an open source project!
I have several questions:
How do I switch from TC to VC? I already installed VC but what is next? Can I simply convert the TC sysystem partition to VC? Or do I simply have to deinstall TC? When I do that, is the system partition bootable or is the TC driver then deinstalled, too?
When I encrypted my SSD with TC I did the following: I left 10 percent of the SSD unpartitioned and I encrypted the partition. Was that wrong? Should I encrypt the whole drive or does it make sense to let 10 percent free so that wear leveling is working and the SSD has room to manage the wear? Of course I had no sensible data on the SSD before encrypting, so that should be no problem.
My CPU has AES support and my SSD is AES encrypted, but of course the speed, especially the random data speed, is really low in comparison to the non encrypted drive. Are there plans to speed up the software for SSDs? Diskcryptor for example is a lot faster on SSDs so it is possible to tweak the software.
Are you guys working with CipherShed at the moment? They are doing a TC-Fork too and it would be wasted ressources if you would do two seperate projects if you could put your work together instead...
Thanks for the help!
Hi,
Thank you for your kind words.
If your TC volumes (containers, non-system partition) were created with version 7.0 and above, then you can convert them to VC format through the change password operation. This doesn't apply to encrypted system partitions (this appears to be your case). For now, the conversion of TC system partitions is not implemented and as such you have to keep TC in such case. TC and VC can run on the same machine with no conflicts so you can for example keep TC for your system encryption and use VC for containers and non-system partitions. The other options is to decrypt your system and encrypt it back using VC, but this can take a long time and it is not something that everybody wishes to do. That's why the conversion of TC system partitions in on the agenda for the next release.
Generally speaking, wear leveling is an enemy for disk encryption but its effects can be mitigated by following strict rules described in the documentation (https://veracrypt.codeplex.com/wikipage?title=Wear-Leveling). In light of these rules, leaving 10% of the SSD unpartitioned after the encryption is the wrong thing to do as it breaks the security model of disk encryption. As explained in the documentation, the obvious example if the password change operation: because of the wear-leveling, the new volume header will most probably be created in the empty 10% space and the old volume header will remain on the disk, thus leaving an attacker with a way to decrypt the data if the old password is weak or compromised. As a rule, always encrypt the whole SSD before use.
AES-NI is implemented to from that side, so TC and VC use full AES encryption speed. Can you give more details about the data speed? any benchmarks? For read operations, I don't see how TC or VC can be slow compared to other software since only the encryption layer adds an overhead and thanks to the AES hardware we use the maximum available capacity. For write operations, the TRIM operation of SSD is not blocked by TC or VC except of the hidden system, so also in this case, only the encryption adds an overhead. It would help if you have any reference or data that compares TC/VC and DiskCryptor and that gives the exact context of comparison.
The VeraCrypt project starts in 2013 long before the TrueCrypt demise and thus before the CipherShed fork. After the TrueCrypt end, I was contacted by Bill Cox who is behind CipherShed and he proposed to join his project. For me, it was more logical that people join VeraCrypt since the foundation is already here. But in cases like, it is difficult to have more that one captain in a ship and the CipherShed project went ahead. Personnaly, I have nothing against, on the contrary, I believe that the it is very good diversity in open source encryption offering and at any time CipherShed or VeraCrypt can benefit from the work done on the other project. Another point is that VeraCrypt is a pure Continental European project (well, French to be precise) while the CipherShed project is US/UK based. So, fatally, there is a culture difference that make our approaches different. With the latest revelation about NSA/GCHQ, there is strong demand for stronger encryption and VeraCrypt choose this path from the beginning with a policy of quick releases, CipherShed on the other hand has a compatibility approach that basically keeps TrueCrypt living without offering any stronger security on the short term. On the organization side, CipherShed people are doing an amazing job and things are handled professionally which is good on the long term but it makes things slower and there is no clear commitment about the strength of the encryption they will be offering in the future. Personally I remain open to any cooperation although I would have preferred that the project be managed on the development side from Continental Europe and not the US/UK for obvious reasons.
Last edit: Mounir IDRASSI 2015-01-03
Thanks for your looooooooooong reply! You take so much time for this project someone could think a big agency overseas would fund you! (just a joke...)
Alright, so I guess I will just decrypt and encrypt the whole SSD then.
I previously read that article but I do not understand why it is unsafe to leave 10 percent free and not permanent encrypted and how the wear leveling should work if the whole disk is encrypted. I understand that having sensible data not encrypted on the SSD and then the SSD encrypted then there is the possibility that the data is still available on some flash cells (although it would be really hard to get the data out because the controller can not be switched without loosing the data that is encrypted be default by the SSD controller). But after VC is installed all data is encrypted except the volume header (possibly) so the only problem is that you could switch out a new bootloader with an old password. Or is Windows able to bypass the VC encryption driver and write clear data to the unpartitioned 10 percent that is free? So why is it unsafe to have a wear leveling drive that is encrypted to 100 percent by VC? Then there is no other place where Windows could put data unencrypted. In the link there is not explained if wear leveling can work when the drive is 100 percent encrypted, I understood that it can't work because VC writes the whole drive full of "random" data that the SSD controller can not analyze or move so the wear leveling technology can not write data to SSD cells that have not been used much and that increases the wear drastically. So when my understanding is not wrong then leaving the 10 percent free is not a problem other than that an old volume header could possibly be reactivated. So I should keep TC for the system partition until VC can transform it to VC, otherwise I would have to decrypt the drive and encrypt it again with VC but that would be unwise cause then decrypted data might be stored in the 10 percent that is not encrypted with VC. Right? I am confused now. And some people say that modern SSDs have 10-15% spare room for situations where the whole SSD is written full so it is no problem to encrypt it to 100 percent.
Here is my system: Samsung 840 Evo + i7-5820k + GTX 970
Without TC encryption I have 540 MB/s sequential read, 520 sequential write, 98.000 direct read and 90.000 direct write like Samsung says.
With encryption and 10 percent free space I have 334 sequential read, 369 sequential write, 8421 direct read (IOPS) and 21847 direct write (IOPS).
Thats still a lot better than a HDD but I am loosing a lot IOPS.
Here is one of the many tests that have been done to compare Diskcryptor and TC on SSDs: http://blog.alexou.net/?truecrypt-vs-diskcryptor-on-ssd-windows-7-fd
In the Diskcryptor forums there are several discussions about tweaking the SSD performance ( https://diskcryptor.net/forum/index.php?topic=1962.0 ) and it works...
I indeed invest a lot of my personal time on this project especially since the collapse of the TrueCrypt when the need of a strong alternative was felt more strongly. This could not happen without the support and the patience of my wife who always encourages me as she understands the importance of this work.
I would feel proud if someone thinks that a big agency is behind me as VeraCrypt is my brainchild who is growing through my dedication and my 14 years experience in the security field. This also can help people imagine what a big agency like the NSA can do with thousands of talented employees who only focus on specific tasks without worrying about their monthly paycheck...
I didn't say that it is "unsafe to have a wear leveling drive that is encrypted to 100 percent by VC". At the contrary, full encryption is a mitigation to the risks of wear-level. I don't see any confusion, you just have to take things more simply. Windows can't circumvent VC or TC. The issue is with the SSD controller who may leave cells containing old data. From this simple fact, you can build all the security threats.
I also see only the leak of the old header as the potential threat. If there were no confidential data before the encryption, then this should be the only risk.
That being said, as my experience tells me, I always define a security perimeter larger than what my current knowledge tells me to do because attacks get always better and never worse.
Of course, I'm not an expert on SSD technology and its internals. Things are advancing fast and modern controller are becoming complex so their behavior is difficult to judge without painstaking real-world tests. There are simple rules that apply to flash based storage and that helps define basic security rules. I leave to others the work of studying how modern SSDs are behaving with Full Disk Encryption solutions like VeraCrypt.
Thanks for the links and information concerning the TC benchmarks. I'll have to study the subject more in details.
Last edit: Mounir IDRASSI 2015-01-04
I already answered but I think there was an error because it was not published.
Short form: I asked for the feature to transform the TC system partition to a VC system partition (decrpyting on an SSD and then encrypting again is not safely possible). I think you are already working on that, but just to show you that more people would ike that I asked for it again.
Thank you very much!