This project has moved. For the latest updates, please go here.

TrueCrypt options have to go

Topics: Feature Requests, Technical Issues
Aug 15, 2015 at 9:50 PM
I really think that in the future releases of VC, all TC options (mount as TC volume) have to go. There is absolutely no need to keep any backward compatibility with TC anymore. If someone is using TC format containers/partitions, he can use TC 7.1a to access them. If he opts for VC, then he can (and that is the most secure way) mount the TC container/partition with TC 7.1a, create VC container/partition with VC and copy his files to the new location. In the extreme scenario that he can not find a reliable TC installation, he can still download VC 1.13 or earlier and do the same.

TC compatibility only confuses the less experienced VC users (as we see from other threads where people can not mount their volumes), makes the VC software more complicated and heavier, compromises the security model (less iterations), etc.
Aug 16, 2015 at 1:43 AM
Edited Aug 16, 2015 at 1:43 AM
TrueCrypt went out of business in May 2014, which may seem like a long time ago but really isn't.

A better approach might be to check for the appearance of TrueCrypt format after any attempt to open a Veracrypt container fails. If TrueCrypt format is detected, then warn the user that the volume appears to be a TrueCrypt container, etc. and suggest activating the TrueCrypt mode. Or just skip the user interaction and go straight into TrueCrypt mode if Veracrypt mode fails and the container looks like it's in TrueCrypt format.
Aug 16, 2015 at 2:06 AM
Be aware that the TC switch is still needed for converting non-system TC volumes to VC.

https://veracrypt.codeplex.com/wikipage?title=Converting%20TrueCrypt%20volumes%20and%20partitions
Aug 16, 2015 at 8:13 AM
There is no need for any checks for TC volumes present, there is no need for any conversions.... all these can be done (if needed) with the TC 7.1a or older versions of VC. VC has to continue on its own.... if someone still wants to use TC - fine, but why integrate 2 programs/formats into one?....
Aug 16, 2015 at 3:54 PM
Edited Aug 16, 2015 at 4:55 PM
Hello Alex,

The history of this feature is due to people kept asking for a way to mount their TC volumes in VC and a way to convert them to VC without having to decrypt or create new volumes due to the size of the volumes can be very large or the entire HDD. People requesting this feature did not have the spare disk space or devices to perform a old/new volume conversions.

Mounir agreed and he coded VC to be able to mount TC versions 6.x or higher as a user friendly solution to view or upgrade their non-system volumes to VC without having to decrypt or build new volumes.

Both TC and VC are using the same header key format that is used to retrieve the encryption key. In this context, the only difference between TC and VC is the number iterations performed to encrypt/decrypt the header key and in VC the removal of creating new volumes using RIPEMD-160 hash with the ability to use SHA-256 hash for new volumes.

In regards to your request which stems from the thread below. I would like forum member ShadeTreePC to clear-up some confusion I have about his statements in the thread below.

https://veracrypt.codeplex.com/discussions/643743

Did ShadeTreePC have TC file containers that he forgot he was mounting using the TC Mode switch? Or did ShadeTreePC have VC file containers and for some inexplicable reasons, he enabled the TC Mode? Or did ShadeTreePC have a mix of both TC and VC file containers?

I like commenter8's idea since the TC iteration count would add maybe 1 to 2 seconds to the mount time after the failed VC volume mount in order to attempt mounting in TC mode.

Kind Regards.