6

TrueCrypt retired with a mysterious "Using TrueCrypt is not secure as it may contain unfixed security issues" (source)

Yesterday Slashdot reported VeraCrypt as a better replacement (source) since it bumps up several KDF iteration values (probably just #defines in the code :/ )

Why is this so? I doubt the original issue with TrueCrypt was the iteration values since hacking any KDF with any decent sized passphrase is still extremely difficult. In other words, I doubt it's the KDF that was the weak point to begin with, so VeraCrypt's changes appear like installing a steel vault door on a house with plenty of glass windows.

So, on what evidence can we consider VeraCrypt more secure than TrueCrypt?

2
  • 1
    I am deeply concerned for the participants in that thread. Oct 14, 2014 at 18:23
  • Anyways if all he did was bump up the iterations and stamp Vera on it, why bother? I'd opt for something that is interface driven, plug in the KDF of your choosing, encryption algorithm of your choosing, etc. Oct 14, 2014 at 18:40

2 Answers 2

4

Only through code review and testing.

Changes in iterations may indeed make those areas of the code more resilient to brute-forcing, but iterations are only a part of the overall architecture that needs to be considered.

5
  • While I 100% agree with your comment, it doesn't actually address the question. Oct 14, 2014 at 18:43
  • 1
    Then perhaps your questions needs to be fleshed out? Perhaps, "how is 327,661 iterations of the PBKDF2-RIPEMD160 algorithm demonstrably more secure than 1,000 iterations"? In which case, you might need to migrate this over to crypto.SE
    – schroeder
    Oct 14, 2014 at 18:58
  • No, the question is at the right balance of generality and specificity. It intentionally defocuses on specific details like KDR iterations while addressing overall security. You answer 'how' while I'm asking 'why'. Oct 14, 2014 at 19:46
  • The problem with your question is that there isn't enough for us to work with. We need to perform a code review in order to answer your question. We need either specific questions (like my proposed question) or enough details to work with a general question. Why is it more secure? Because more iterations. Is more iterations more secure? Depends: ask the crypto experts, or let us delve into the guts if the rest of the app. Either way, your underlying question is difficult to answer.
    – schroeder
    Oct 14, 2014 at 19:56
  • I was hoping there would be more than just "moar iterations FTW" and looks like that's the case. Check out the answer below. Oct 15, 2014 at 0:48
2

Right from the project maintainer ... (credit to this thread)

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 TC_IOCTL_GET_SYSTEM_DRIVE_DUMP_CONFIG kernel pointer disclosure: fixed since version 1.0e

  4. IOCTL_DISK_VERIFY integer overflow: fixed since version 1.0e

  5. MainThreadProc() integer overflow: fixed since version 1.0e
  6. MountVolume() device check bypass: fixed since version 1.0e
  7. 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,

7
  • Info dump of external site page. Oct 15, 2014 at 0:57
  • The whole Q&A post has a POV flavour to it. A straight up repost of VeraCrypt project news doesn't help. Answers that are just a link to a third party site are downvoted for much the same reason. Condense the article into its salient points and I'll drop the downvote. Oct 15, 2014 at 1:08
  • 2
    It's not your downvote that's important (it's just a counter in some database somewhere). The informational content is king, so that's why the above. Plus your entire argument is pedantic and unproductive. Oct 15, 2014 at 1:12
  • 1
    Agreed; and anyone is welcome to downvote or upvote answers on the basis of their content, presentation and origin. This is particularly relevant as stack exchanges' cc-by-sa 3.0 is difficult to apply to reposted content of other authors. Oct 15, 2014 at 1:26
  • 1
    The problem is that this is not public scrutiny: this data is from the author. I believe my point is still valid. In order to answer your question "what evidence that VC is more secure than TC," we need code review and testing. It's great that the author provides this info, but it is not relevant to your stated question. If your underlying question is answered by this, great, but then I suggest modifying your original post.
    – schroeder
    Oct 15, 2014 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .