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

Why is this more secure than TrueCrypt?

Topics: Technical Issues
Oct 14, 2014 at 5:28 PM
I understand you've bumped up the iterations. However, TrueCrypt disappeared with a mysterious "contains unfixed security issues" message. It is extremely unlikely that the original message from TrueCrypt referred to the iteration constants you changed since brute forcing the algorithm, even with TrueCrypt's chosen numbers, is extraordinarily difficult/infeasible with a decent sized passphrase.

So the key question is:

Which of these TrueCrypt security issues are fixed in VeraCrypt? On the flip side, how much of the code has been inherited from TrueCrypt that would mitigate this risk?

Thanks
Coordinator
Oct 14, 2014 at 10:19 PM
VeraCrypt not only enhances security over the original TrueCrypt through an increased iterations count, but it also solves all the serious security issues and weaknesses discovered so far in the source code. A good list of these weaknesses can be found in the https://opencryptoaudit.org/reports/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf

We have documented these security changes in the git commits. The important ones start with "Windows vulnerability fix" and "Static Code Analysis".
I'll use the list if the Open Crypto Audit project :
  1. Weak Volume Header key derivation algorithm: fixed since the birth of VeraCrypt. As of 2014, any security professional will tell you that PBKDF2 should be used with a minimum of 10000 iteration for a high security, combined with a strong password. The 1000 count comes from 2004 and it is outdated, and that's why the Open Crypto Audit placed it as the first vulnerability. In VeraCrypt, we choose since 2013 a very high iterations count to meet the increasing security requirements, hopefully for the next 10 years.
  2. Multiple issues in the bootloader decompressor : fixed in git and it will be released in version 1.0f. This was very challenging because of the size requirements of the bootloader. We had to optimize the code size of many part in order to make room for the modifications of the decompressor.
  3. Windows kernel driver uses memset() to clear sensitive data: fixed since version 1.0e
  4. TC_IOCTL_GET_SYSTEM_DRIVE_DUMP_CONFIG kernel pointer disclosure: fixed since version 1.0e
  5. IOCTL_DISK_VERIFY integer overflow: fixed since version 1.0e
  6. MainThreadProc() integer overflow: fixed since version 1.0e
  7. MountVolume() device check bypass: fixed since version 1.0e
  8. GetWipePassCount() / WipeBuffer() can cause BSOD: fixed since version 1.0e
Moreover, the VeraCrypt source code has ben checked using two static code analyzer tools and they reported many issues that were solved (commits starting with "Static Code Analysis"). One of the most time consuming part was the complete rewrite of string manipulation code in order to use Safe String functions instead of the vulnerable string.h ones (both in user mode and kernel mode). Other fixes included :
  • correcting memory leaks
  • fixing potential overflow when parsing language file that can exploited.
  • fixing non-absolute DLL/process loads that can be hijacked (Microsoft Security Advisory 2269637).
While we inherited much of the code of TrueCrypt, we have introduced many modifications and corrections that enhances the overall security with a big margin. Of course, most of these modifications are invisible to the general user but security experts can easily checks the current state of the code and validate our approach.

I'm taking this opportunity to announce that we have been able to implement SHA-256 key derivation for system boot encryption (200 000 iterations). TrueCrypt has been always supporting only RIPEMD-160 for system partition encryption and this clearly needed an upgrade because of the aging RIPEMD-160 even if no public attack exists for it. Because of different limitations in the boot loader (code size, memory), this was not an easy task and we had to introduce optimizations and new bootloader management in the VeraCrypt formating program in order to be able to support RIPEMD-160 and SHA-256 at the same time.

We'll publish soon a beta version of VeraCrypt 1.0f that will include this SHA-256 in order to have feedback from users.

For those who wonder why we implemented SHA-256 and not SHA-512 for the bootloader, the answer is that it was not possible to implement SHA-512 in the 16-bit environment of the bootloader because it needs 64-bit operations which can't be decomposed efficiently into 16-bit operations. On the other hand, SHA-256 uses 32-bit operations which adapts easily to the 16-bit environment even if we lose performance.

Voila voila...I hope I have been able to answer your questions and to show how VeraCrypt is a descent secure alternative to TrueCrypt.

Cheers,
Oct 15, 2014 at 1:23 AM
Thanks for the detailed response.

Are the original auditors from iSEC still involved? IMHO, you should see if you can have additional developers/auditors join the project.
Coordinator
Oct 15, 2014 at 3:04 PM
The iSEC people were enlisted and payed by the Open Crypto Audit project in order to perform the audit, so I think now that the report is finalized their mission is over.

I contacted the Open Crypto Audit project to have their feedback about VeraCrypt and to see how we can collaborate. I'll let you know if they answer my request.
Jan 2, 2015 at 12:07 AM
I don't understand why RIPEMD-160 has to go. If no attacks on it have been found for decades, that makes it a better choice rather than a worse one, right? Or is the aging relevant because new facts have been discovered about hash functions that could be used against RIPEMD-160?
Coordinator
Jan 2, 2015 at 9:54 AM
RIPEMD-160 was deprecated for containers and non-system partitions because of its aging design. Indeed, there are no publicly know attack on RIPEMD-160 but this doesn't mean it is secure: it didn't receive as much attention as other hash algorithms because of its limited use.

RIPEMD-160 is still supported for system encryption because we don't want to rely only on SHA-256.
For containers and non-system partition, Whirlpool is a good alternative to SHA-512 and SHAR-256 and it has been well studied.

In the future, other well-proven hash algorithms will be included.
Jan 8, 2015 at 6:14 PM
idrassi wrote:
RIPEMD-160 was deprecated for containers and non-system partitions because of its aging design. Indeed, there are no publicly know attack on RIPEMD-160 but this doesn't mean it is secure: it didn't receive as much attention as other hash algorithms because of its limited use.

RIPEMD-160 is still supported for system encryption because we don't want to rely only on SHA-256.
For containers and non-system partition, Whirlpool is a good alternative to SHA-512 and SHAR-256 and it has been well studied.

In the future, other well-proven hash algorithms will be included.
I would ask the implementation of Scrypt http://en.wikipedia.org/wiki/Scrypt

I think it would be a great update :-)
Jan 8, 2016 at 11:06 AM
TCalhau wrote:
idrassi wrote:
In the future, other well-proven hash algorithms will be included.
I would ask the implementation of Scrypt http://en.wikipedia.org/wiki/Scrypt

I think it would be a great update :-)
Even better would be to use a hybrid e.g. SHA-256 + bcrypt + scrypt. Even if one of them proves vulnerable the whole system remains ultra-secure.
Sep 21, 2016 at 12:07 AM
Yes it is ultra secure. Idrassi, thank you for this. Well done!