backwards compatibility?

Topics: Technical Issues
Aug 12, 2014 at 10:07 AM
dear people at veracrypt,
good to hear, that someone cares about the continuation of truecrypt!
just my two pence:
  • I also would appreciate uefi/gpt-support very much , but I realize this to be a VERY complicated task indeed....
  • Something easier maybe: would it be a big deal to make VC backwards compatible with existing TC-containers/partitions etc.? That would be very helpful, since one could use only one cryptsoft and wouldn't have to de- and recrypt everything.... (at least 13 disks and partitions in my case...). Simply to mount/read/write old TC-stuff would be sufficient, creation of new tc-containers is not necessarily necessary....
thank you for a short reply and keep on the good work!

Aug 12, 2014 at 7:12 PM
Hi Andrej,

Thank you for your feedback and encouragement.

UEFI/GPT support is an estimated 6 man-months task. Once we finalize the development of the remaining features and tasks, we can start work on it. If everything goes well, we should have a working implementation in one year from now (mid 2015).

Backward compatibility is on the agenda. Our first idea is to have a conversion tool that will convert TrueCrypt volumes to VeraCrypt format. It will be quick since it only affects headers. We are seeing more people asking for integrating this inside VeraCrypt directly so we are starting to consider this. The only point is that we can't support all version of TrueCrypt : we can support only volumes created by TrueCrypt 7.x family. Are you in this case?
Aug 13, 2014 at 11:47 AM
Hi idrassi,

thanks for your fast reply! Uefi-schedule sounds good to me.
Btw., are there some whitepapers or technical documentations that deal with the specific difficulties? just curious, what it might be....

Your plan to offer only 7.x-TC-conversion sounds perfectly sensible. I always used the latest version of TC, so I am "in the case".

Is the conversion you are planning also possible with tc-partitions (as far as only headers are concerned, it should work)? If not, maybe at least a semiautomatic procedure might be helpful, de- and recrypting things with the same password if there's no "direct" way to do this.

One last question: in which respects does the vc-container-format differ from the established tc?

best wishes and looking forward to your next steps,

Aug 15, 2014 at 3:46 PM
Hi Andrej,

VC container format is based on TC 7.x format, changing only header magic and version constant, both for the main header and the backup header. Of course, the encryption of the header is different between the two but this doesn't affect the conversion. Thus it should be easy to implement without the need of re-encrypting the volume or the partition.

No documentation exists today about the technical difficulties of implementing UEFI for VeraCrypt. One should be written in order to help designing the best solution. For now, we lack expertise in UEFI programming but we are working towards that. There are projects were we can find pieces of the solution that we need, like Grub for example. Another potential difficulty is the fact that Microsoft implemented security features in Windows ensuring that only signed bootloader is accepted in UEFI mode and I don't think they will accept to sign VeraCrypt bootloader! So probably the user will have to perform manuel steps in order to deactivate such verification before encrypting system partition with VeraCrypt.

We welcome any ideas or help from the community on this subject.
Sep 13, 2014 at 11:41 AM
Edited Sep 13, 2014 at 11:43 AM
What is the problem about backward compatibility? Afaik the only dfference is the number of iterations. So why not do the 1000/2000 iterations, check whether it is possible to mount the volume and then continue with the other iterations? This should not effect perfromance very much - especially if the mounting test was done by a seperate thread.
Sep 14, 2014 at 8:17 AM

First of all, we removed in VeraCrypt many of the legacy code that was in TrueCrypt to handle different types of encoding and encryption that were present since the beginning of TrueCrypt. Keeping this in VeraCrypt made no sens. Thus, only volumes created with TrueCrypt 7.x have the potential to be supported.

Concerning the iterations count, we already had the same idea of having a midway check using the low TrueCrypt count before continuing with the full iterations count. It seems easy like that but it would introduce a rather big complexity in the code for no big advantage. There are many components involved in the decryption of volume headers with the use of threads pool and most importantly of all, the derivation functions are kept separated from the volume handling logic and the bootloader specifics.
Implementing this would have required a huge architecture change which would have been a wast of resources : continue to support the weak TrueCrypt derivation function has never been an objective of VeraCrypt and for security conscious users stopping the use of TrueCrypt must be a priority.

We understand that there are many people left with TeraBytes of data encrypted with TrueCrypt and for them a switch to VeraCrypt is not easy. That's why we were thinking since the beginning of implementing a migration tool that would convert TrueCrypt 7.x volumes and partitions to VeraCrypt format. Unfortunately, there are so many tasks to be done for VeraCrypt and we don't have enough time to implement such tool.

From your posts, you seems to have good technical knowledge, so if you are interested you can participate in the development of such compatibility tool. We welcome all developers to come and participate in VeraCrypt as its sole purpose is to be useful to the community. Of course, it is a pretty complex piece of software but we can help new comers diving easily into it.